<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bier-evpn-14" number="9624" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2024-08-31T12:05:34" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bier-evpn-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9624" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="EVPN BUM Using BIER">EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER)</title>
    <seriesInfo name="RFC" value="9624" stream="IETF"/>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <email>prz@juniper.net</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>RTF</area>
    <workgroup>BIER</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies protocols and procedures for forwarding
         Broadcast, Unknown Unicast, or Multicast (BUM) traffic
         of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9624" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-pmsi-tunnel-attr">Use of the PMSI Tunnel Attribute</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-based-tunnel-and-bier-ph">IP-Based Tunnel and BIER PHP</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-explicit-tracking">Explicit Tracking</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-imet-smet-routes">Using IMET/SMET Routes</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.2.1"><xref derivedContent="2.2.2" format="counter" sectionFormat="of" target="section-2.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-s-pmsi-leaf-a-d-route">Using S-PMSI/Leaf A-D Routes</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mpls-label-in-the-pta">MPLS Label in the PTA</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multihoming-split-horizon">Multihoming Split Horizon</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-plane">Data Plane</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulation-and-transmiss">Encapsulation and Transmission</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at-a-bfir-that-is-an-ingres">At a BFIR That Is an Ingress PE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at-a-bfir-that-is-a-p-tunne">At a BFIR That Is a P-Tunnel Segmentation Point</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disposition">Disposition</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at-a-bfer-that-is-an-egress">At a BFER That Is an Egress PE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at-a-bfer-that-is-a-p-tunne">At a BFER That Is a P-Tunnel Segmentation Point</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> specify
       the protocols and procedures for Ethernet VPNs (EVPNs). For Broadcast,
       Unknown Unicast, or Multicast (BUM) traffic, provider/underlay tunnels
       are used to carry the BUM traffic. Several
       kinds of tunnel technologies can be used as specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and
	   <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>, and this document specifies the protocols and procedures to
	   use Bit Index Explicit Replication (BIER)
   <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> as provider tunnels for EVPN BUM traffic.
      </t>
      <t indent="0" pn="section-1-2">
   BIER is an
   architecture that provides optimal multicast forwarding through a
   "multicast domain" without requiring intermediate routers to
   maintain any per-flow state or to engage in an explicit tree-building
   protocol.
      </t>
      <t indent="0" pn="section-1-3">
       The EVPN BUM procedures specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and extended in <xref target="RFC9572" format="default" sectionFormat="of" derivedContent="RFC9572"/>, <xref target="RFC9251" format="default" sectionFormat="of" derivedContent="RFC9251"/>, and <xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="default" sectionFormat="of" derivedContent="CMCAST-ENHANCEMENTS"/>
       are much aligned with Multicast VPN (MVPN) procedures <xref target="RFC6514" format="default" sectionFormat="of" derivedContent="RFC6514"/>,
	   and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN.
	   As such, this document is also very much aligned with <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>, which specifies MVPN with BIER.
       For terseness, some background, terms, and concepts are not
       repeated here. Additionally, some text is borrowed verbatim from
       <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl newline="false" spacing="normal" indent="3" pn="section-1.1-1">
          <dt pn="section-1.1-1.1">ES:</dt>
          <dd pn="section-1.1-1.2">Ethernet Segment</dd>
          <dt pn="section-1.1-1.3">ESI:</dt>
          <dd pn="section-1.1-1.4">Ethernet Segment Identifier</dd>
          <dt pn="section-1.1-1.5">BFR:</dt>
          <dd pn="section-1.1-1.6">Bit-Forwarding Router</dd>
          <dt pn="section-1.1-1.7">BFIR:</dt>
          <dd pn="section-1.1-1.8">Bit-Forwarding Ingress Router</dd>
          <dt pn="section-1.1-1.9">BFER:</dt>
          <dd pn="section-1.1-1.10">Bit-Forwarding Egress Router</dd>
          <dt pn="section-1.1-1.11">BFR-Prefix:</dt>
          <dd pn="section-1.1-1.12">An IP address that uniquely identifies a BFR
            and is routable in a BIER domain.</dd>
          <dt pn="section-1.1-1.13">C-S:</dt>
          <dd pn="section-1.1-1.14">A multicast source address identifying a multicast source
          located at an EVPN customer site. "C-" stands for "Customer-".
            </dd>
          <dt pn="section-1.1-1.15">C-G:</dt>
          <dd pn="section-1.1-1.16">A multicast group address used by an EVPN customer.</dd>
          <dt pn="section-1.1-1.17">C-flow:</dt>
          <dd pn="section-1.1-1.18">A customer multicast flow.  Each C-flow is identified by
          the ordered pair (source address, group address), where each
          address is in the customer's address space.  The identifier of a
          particular C-flow is usually written as (C-S, C-G).
          Sets of C-flows can be denoted by the use of the "C-*" wildcard
          (see <xref target="RFC6625" format="default" sectionFormat="of" derivedContent="RFC6625"/>), e.g., (C-*, C-G).</dd>
          <dt pn="section-1.1-1.19">P-tunnel:</dt>
          <dd pn="section-1.1-1.20">A multicast tunnel through the network of one or more
          service providers used to transport C-flows. "P-" stands for "Provider-".
            </dd>
          <dt pn="section-1.1-1.21">IMET A-D Route:</dt>
          <dd pn="section-1.1-1.22">Inclusive Multicast Ethernet Tag
          Auto-Discovery route.  Carried in BGP Update messages, these
          routes are used to advertise the "default" P-tunnel for a
          particular BD.</dd>
          <dt pn="section-1.1-1.23">SMET A-D Route:</dt>
          <dd pn="section-1.1-1.24">Selective Multicast Ethernet Tag
          Auto-Discovery route.  Carried in BGP Update messages, these
          routes are used to advertise the C-flows that the advertising Provider Edge (PE)
          is interested in.</dd>
          <dt pn="section-1.1-1.25">PMSI:</dt>
          <dd pn="section-1.1-1.26">Provider Multicast Service Interface <xref target="RFC6513" format="default" sectionFormat="of" derivedContent="RFC6513"/>. A conceptual interface used by a PE
          to send customer multicast traffic to all or some PEs in the same
          VPN.</dd>
          <dt pn="section-1.1-1.27">I-PMSI:</dt>
          <dd pn="section-1.1-1.28">Inclusive PMSI. For all PEs in the same VPN.</dd>
          <dt pn="section-1.1-1.29">S-PMSI:</dt>
          <dd pn="section-1.1-1.30">Selective PMSI. For some of the PEs in the same VPN.</dd>
          <dt pn="section-1.1-1.31">I-PMSI A-D Route:</dt>
          <dd pn="section-1.1-1.32">Inclusive PMSI Auto-Discovery route used to advertise the tunnels that instantiate an I-PMSI.</dd>
          <dt pn="section-1.1-1.33">S-PMSI A-D Route:</dt>
          <dd pn="section-1.1-1.34">Selective PMSI Auto-Discovery route used to advertise that particular C-flows are
          bound to (i.e., are traveling through) particular P-tunnels.</dd>
          <dt pn="section-1.1-1.35">PTA:</dt>
          <dd pn="section-1.1-1.36">PMSI Tunnel Attribute. A BGP attribute used
          to identify a particular P-tunnel.</dd>
          <dt pn="section-1.1-1.37">VXLAN:</dt>
          <dd pn="section-1.1-1.38">Virtual eXtensible Local Area Network <xref target="RFC7348" format="default" sectionFormat="of" derivedContent="RFC7348"/></dd>
          <dt pn="section-1.1-1.39">NVGRE:</dt>
          <dd pn="section-1.1-1.40">Network Virtualization Using Generic Routing Encapsulation  <xref target="RFC7637" format="default" sectionFormat="of" derivedContent="RFC7637"/></dd>
          <dt pn="section-1.1-1.41">GENEVE:</dt>
          <dd pn="section-1.1-1.42">Generic Network Virtualization Encapsulation <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/></dd>
          <dt pn="section-1.1-1.43">VNI:</dt>
          <dd pn="section-1.1-1.44">VXLAN Network Identifier</dd>
          <dt pn="section-1.1-1.45">VSID:</dt>
          <dd pn="section-1.1-1.46">Virtual Subnet Identifier</dd>
          <dt pn="section-1.1-1.47">RSVP-TE P2MP:</dt>
          <dd pn="section-1.1-1.48">Resource Reservation Protocol for Point-to-Multipoint TE Label Switched Paths (LSPs) <xref target="RFC4875" format="default" sectionFormat="of" derivedContent="RFC4875"/></dd>
          <dt pn="section-1.1-1.49">mLDP P2MP:</dt>
          <dd pn="section-1.1-1.50">Multipoint Label Distribution Protocol extensions
    for Point-to-Multipoint LSPs <xref target="RFC6388" format="default" sectionFormat="of" derivedContent="RFC6388"/></dd>
        </dl>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="pta" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-use-of-the-pmsi-tunnel-attr">Use of the PMSI Tunnel Attribute</name>
      <t indent="0" pn="section-2-1"><xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> specifies that Inclusive Multicast Ethernet Tag (IMET)
       routes carry a PMSI Tunnel Attribute (PTA) to identify the particular
       P-tunnel to which one or more BUM flows are being assigned, which is the same as
       specified in <xref target="RFC6514" format="default" sectionFormat="of" derivedContent="RFC6514"/> for MVPN.
       <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/> specifies the encoding of the
       PTA for the use of BIER with MVPN. Much of that specification is reused
       for the use of BIER with EVPN, and much of the text below is borrowed
       verbatim from <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>.
      </t>
      <t indent="0" pn="section-2-2">The PTA contains the following fields:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3">
        <li pn="section-2-3.1">
          <t indent="0" pn="section-2-3.1.1">Tunnel Type. The same codepoint 0x0B that IANA has assigned for
	  BIER for MVPN <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/> is used for EVPN as well.
          </t>
        </li>
        <li pn="section-2-3.2">
          <t indent="0" pn="section-2-3.2.1">Tunnel Identifier.  This field contains three subfields for BIER.
	  The text below is exactly as in
        <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>.
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-3.2.2"><li pn="section-2-3.2.2.1" derivedCounter="1.">
              <t indent="0" pn="section-2-3.2.2.1.1">
       The first subfield is a single octet, containing a BIER 
       sub-domain-id (see <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>). This indicates that
       packets sent on the PMSI will be sent on the specified BIER sub-domain.
       How that sub-domain is chosen is outside the scope of this
       document.
              </t>
            </li>
            <li pn="section-2-3.2.2.2" derivedCounter="2.">
              <t indent="0" pn="section-2-3.2.2.2.1">   The second subfield is a two-octet field containing the
          BFR-id in the sub-domain identified in the first subfield of
          the router that is constructing the PTA.    </t>
            </li>
            <li pn="section-2-3.2.2.3" derivedCounter="3.">
              <t indent="0" pn="section-2-3.2.2.3.1">
       The third subfield is the BFR-Prefix (see
       <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>) of the
       router (a BFIR) that is constructing the PTA. The BFR-Prefix will
       either be a /32 IPv4 address or a /128 IPv6 address.  Whether
       the address is IPv4 or IPv6 can be inferred from the total
       length of the PTA.
              </t>
              <t indent="0" pn="section-2-3.2.2.3.2">
          The BFR-Prefix need not be the same IP address that is carried
          in any other field of the x-PMSI A-D route, even if the BFIR
          is the originating router of the x-PMSI A-D route.
              </t>
            </li>
          </ol>
          <t indent="0" pn="section-2-3.2.3">
          </t>
        </li>
        <li pn="section-2-3.3">
          <t indent="0" pn="section-2-3.3.1">MPLS Label.  For EVPN-MPLS <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, this field contains an upstream-assigned
       MPLS label.  It is assigned by the BFIR.  Constraints on how the originating router selects this label are discussed in
       <xref target="label" format="default" sectionFormat="of" derivedContent="Section 2.3"/>. For EVPN-VXLAN/NVGRE/GENEVE
       <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> <xref target="RFC7348" format="default" sectionFormat="of" derivedContent="RFC7348"/> <xref target="RFC7637" format="default" sectionFormat="of" derivedContent="RFC7637"/> <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/>, this field is a 24-bit
       VNI/VSID of global significance.
          </t>
        </li>
        <li pn="section-2-3.4">
          <t indent="0" pn="section-2-3.4.1">Flags.  When the tunnel type is BIER, two of the flags in the
       PTA Flags field are meaningful.  Details about the use of these
       flags can be found in <xref target="tracking" format="default" sectionFormat="of" derivedContent="Section 2.2"/>.
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3.4.2">
            <li pn="section-2-3.4.2.1">
              <t indent="0" pn="section-2-3.4.2.1.1">Leaf Info Required per Flow (LIR-pF) <xref target="RFC8534" format="default" sectionFormat="of" derivedContent="RFC8534"/>
              </t>
            </li>
            <li pn="section-2-3.4.2.2">
              <t indent="0" pn="section-2-3.4.2.2.1">Leaf Info Required (LIR)
              </t>
            </li>
          </ul>
        </li>
      </ul>
      <t indent="0" pn="section-2-4">
   Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D,
   or per-region I-PMSI A-D route, the route <bcp14>MUST NOT</bcp14> be distributed beyond the
   boundaries of a BIER domain.  That is, any routers that receive the
   route must be in the same BIER domain as the originator of the route.
   If the originator is in more than one BIER domain, the route must be
   distributed only within the BIER domain in which the BFR-Prefix in
   the PTA uniquely identifies the originator.  As with all MVPN routes,
   the distribution of these routes is controlled by the provisioning of
   Route Targets.
      </t>
      <section anchor="php-address" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-ip-based-tunnel-and-bier-ph">IP-Based Tunnel and BIER PHP</name>
        <t indent="0" pn="section-2.1-1">When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP header
       (and UDP header in the case of VXLAN/GENEVE) is not included in the BIER
       payload, except when it is known a priori that BIER Penultimate Hop
	   Popping (PHP)
       <xref target="I-D.ietf-bier-php" format="default" sectionFormat="of" derivedContent="BIER-PHP"/> is used in the BIER domain and
       the encapsulation (after the BIER header is
       popped) between the BIER Penultimate Hop and the egress PE does not have
       a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case,
       the full VXLAN/NVGRE/GENEVE encapsulation <bcp14>MUST</bcp14> be used. In the outer
	   IP header, a well-known IP multicast address
       (224.0.0.122 in the case of IPv4 or FF02:0:0:0:0:0:0:14 in the case of IPv6) is used as the destination address, and the 
       egress PEs <bcp14>MUST</bcp14> be set up to receive and process packets addressed to
       the destination address. The address is used for all BDs, and the inner
       VXLAN/NVGRE/GENEVE header will be used to identify BDs.
        </t>
      </section>
      <section anchor="tracking" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-explicit-tracking">Explicit Tracking</name>
        <t indent="0" pn="section-2.2-1">
   When using BIER to transport an EVPN BUM data packet through a BIER
   domain, an ingress PE functions as a BFIR (see
   <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>).  The
   BFIR must determine the set of BFERs to which the packet needs to be
   delivered.  This can be done in either of two ways as described in the following
   two sections.
        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2.1">
          <name slugifiedName="name-using-imet-smet-routes">Using IMET/SMET Routes</name>
          <t indent="0" pn="section-2.2.1-1">Both IMET and SMET routes provide explicit tracking functionality.
          </t>
          <t indent="0" pn="section-2.2.1-2">For an inclusive PMSI, the set of BFERs (egress PEs) includes
       the originators of all IMET routes for a BD. For a selective
       PMSI, the set of BFERs (egress PEs) includes the originators
       of corresponding SMET routes.
          </t>
          <t indent="0" pn="section-2.2.1-3">The SMET routes do not carry a PTA. When an ingress
       PE sends traffic on a selective tunnel using BIER, it uses the upstream-assigned label that is advertised in its IMET route.
          </t>
          <t indent="0" pn="section-2.2.1-4">When only selective forwarding is used for all flows and without tunnel
       segmentation, SMET routes are used without the need for S-PMSI A-D routes.
       Otherwise, the procedures in the following section apply.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2.2">
          <name slugifiedName="name-using-s-pmsi-leaf-a-d-route">Using S-PMSI/Leaf A-D Routes</name>
          <t indent="0" pn="section-2.2.2-1">There are two cases where S-PMSI/Leaf A-D routes are used as discussed
       in the following two sections.
          </t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-2.2.2.1">
            <name slugifiedName="name-selective-forwarding-only-f">Selective Forwarding Only for Some Flows</name>
            <t indent="0" pn="section-2.2.2.1-1">With the SMET procedure, a PE advertises a SMET route for each
      (C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits (ACs), and each SMET
      route is tracked by every PE in the same BD. It may be desired
      that SMET routes are not used in order to reduce the burden of explicit tracking.
            </t>
            <t indent="0" pn="section-2.2.2.1-2">In this case, most multicast traffic will follow the I-PMSI (advertised
       via the IMET route) and only some flows will follow S-PMSIs. To achieve that,
       S-PMSI/Leaf A-D routes can be used, as specified in <xref target="RFC9572" format="default" sectionFormat="of" derivedContent="RFC9572"/>.
            </t>
            <t indent="0" pn="section-2.2.2.1-3">The rules specified in Sections <xref target="RFC8556" section="2.2.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-2.2.1" derivedContent="RFC8556"/> and <xref target="RFC8556" section="2.2.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-2.2.2" derivedContent="RFC8556"/> of <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/> apply.
            </t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-2.2.2.2">
            <name slugifiedName="name-tunnel-segmentation">Tunnel Segmentation</name>
            <t indent="0" pn="section-2.2.2.2-1">Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
       segmentation, which is also specified in <xref target="RFC9572" format="default" sectionFormat="of" derivedContent="RFC9572"/> and further
       clarified in
       <xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="default" sectionFormat="of" derivedContent="CMCAST-ENHANCEMENTS"/> for
       segmentation with SMET routes. This is only applicable to EVPN-MPLS.
            </t>
            <t indent="0" pn="section-2.2.2.2-2">The rules specified in <xref target="RFC8556" section="2.2.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-2.2.1" derivedContent="RFC8556"/> apply. <xref target="RFC8556" section="2.2.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-2.2.2" derivedContent="RFC8556"/> does not apply, because
       like in MVPN, the LIR-pF flag cannot be used with
       segmentation.
            </t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-2.2.2.3">
            <name slugifiedName="name-applicability-of-additional">Applicability of Additional MVPN Specifications</name>
            <t indent="0" pn="section-2.2.2.3-1">As with the MVPN case, "Use of the PMSI Tunnel Attribute
       in Leaf A-D Routes" (<xref target="RFC8556" format="default" sectionFormat="of" section="3" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-3" derivedContent="RFC8556"/>) applies.
            </t>
            <t indent="0" pn="section-2.2.2.3-2">Notice that <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/> refers to procedures
       specified in <xref target="RFC6625" format="default" sectionFormat="of" derivedContent="RFC6625"/> and
       <xref target="RFC8534" format="default" sectionFormat="of" derivedContent="RFC8534"/>. Those two documents
       were specified for MVPN but apply to IP multicast
       payload in EVPN as well.
            </t>
          </section>
        </section>
      </section>
      <section anchor="label" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-mpls-label-in-the-pta">MPLS Label in the PTA</name>
        <t indent="0" pn="section-2.3-1">Rules in <xref target="RFC8556" section="2.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-2.1" derivedContent="RFC8556"/> apply,
       EXCEPT the following three bullets (they do NOT apply to EVPN) in that
       section:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-2">
          <li pn="section-2.3-2.1">
            <t indent="0" pn="section-2.3-2.1.1">
      If the two routes do not have the same Address Family Identifier
      (AFI) value, then their respective PTAs <bcp14>MUST</bcp14> contain different
      MPLS label values.  This ensures that when an egress PE receives a
      data packet with the given label, the egress PE can infer from the
      label whether the payload is an IPv4 packet or an IPv6 packet.
            </t>
          </li>
          <li pn="section-2.3-2.2">
            <t indent="0" pn="section-2.3-2.2.1">
      If the BFIR is an ingress PE supporting MVPN extranet <xref target="RFC7900" format="default" sectionFormat="of" derivedContent="RFC7900"/>
      functionality, and if the two routes originate from different VRFs
      on this ingress PE, then the respective PTAs of the two routes
      <bcp14>MUST</bcp14> contain different MPLS label values.
            </t>
          </li>
          <li pn="section-2.3-2.3">
            <t indent="0" pn="section-2.3-2.3.1">
      If the BFIR is an ingress PE supporting the "Extranet Separation"
      feature of MVPN extranet (see <xref target="RFC7900" section="7.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7900#section-7.3" derivedContent="RFC7900"/>), and if
      one of the routes carries the "Extranet Separation" extended
      community but the other does not, then the respective PTAs of the
      two routes <bcp14>MUST</bcp14> contain different MPLS label values.
            </t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="multihoming" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-multihoming-split-horizon">Multihoming Split Horizon</name>
      <t indent="0" pn="section-3-1">For EVPN-MPLS, <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> specifies the use of ESI labels to identify
       the ES from which a BUM packet originates. A PE receiving that packet
       from the core side will not forward it to the same ES. The procedure
       works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels,
       using downstream- and upstream-assigned ESI labels, respectively. For
       EVPN-VXLAN/NVGRE/GENEVE, <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> specifies local bias
       procedures, where a PE receiving a BUM packet from the core
       side knows the ingress PE due to encapsulation; therefore, the PE
       does not forward the packet to any multihoming ESes that the ingress PE is on. This is
	   because the ingress PE already forwarded the packet to those ESes,
	   regardless of whether the ingress PE is a Designated Forwarder for
	   those ESes.
      </t>
      <t indent="0" pn="section-3-2">With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/GENEVE,
       as the BFIR-id in the BIER header identifies the ingress PE.
       For EVPN-MPLS, ESI label procedures also still apply, though two upstream-assigned labels will be used (one for identifying the BD
       and one for identifying the ES) -- the same as in the case of using
       a single P2MP tunnel for multiple BDs. The BFIR-id in
       the BIER header identifies the ingress PE that assigned those
       two labels.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-data-plane">Data Plane</name>
      <t indent="0" pn="section-4-1">Like MVPN, the EVPN application plays the role of the "multicast
       flow overlay" as described in <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>. 
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-encapsulation-and-transmiss">Encapsulation and Transmission</name>
        <t indent="0" pn="section-4.1-1">A BFIR could be either an ingress PE or a P-tunnel segmentation point.
       The procedures are slightly different as described below.
        </t>
        <section anchor="ingresspe" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-at-a-bfir-that-is-an-ingres">At a BFIR That Is an Ingress PE</name>
          <t indent="0" pn="section-4.1.1-1">To transmit a BUM data packet, an ingress PE first determines the
       route matched for transmission and routes for tracking leaves according
       to the following rules.
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1.1-2"><li anchor="inclusive" pn="section-4.1.1-2.1" derivedCounter="1.">
              <t indent="0" pn="section-4.1.1-2.1.1">If selective forwarding is not used or is not an IP multicast packet
       after the Ethernet header, the IMET route originated for the BD by the
       ingress PE is the route matched for transmission. Leaf-tracking routes
       are all other received IMET routes for the BD.
              </t>
            </li>
            <li pn="section-4.1.1-2.2" derivedCounter="2.">
              <t indent="0" pn="section-4.1.1-2.2.1">Otherwise, if selective forwarding is used for all IP multicast traffic
       based on SMET routes, the IMET route originated for the BD by the ingress
       PE is the route matched for transmission. Received SMET
       routes for the BD, whose source and destination address fields match
	   the packet's source and destination IP address,
       are leaf-tracking routes.
              </t>
            </li>
            <li pn="section-4.1.1-2.3" derivedCounter="3.">
              <t indent="0" pn="section-4.1.1-2.3.1">Otherwise, the route matched for transmission is the S-PMSI A-D route
       originated by the ingress PE for the BD,
       whose source and destination address fields match the packet's source and
       destination IP address and have a PTA specifying a valid tunnel type that
       is not "no tunnel info". Leaf-tracking routes are determined
       as follows:
              </t>
              <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-4.1.1-2.3.2"><li pn="section-4.1.1-2.3.2.1" derivedCounter="a.">
                  <t indent="0" pn="section-4.1.1-2.3.2.1.1">If the match for the transmission route carries a  PTA that has the LIR
           flag set but does not have the LIR-pF flag set, the routes matched for
           tracking are Leaf A-D routes whose Route Key field is identical to
           the NLRI of the S-PMSI A-D route.
                  </t>
                </li>
                <li pn="section-4.1.1-2.3.2.2" derivedCounter="b.">
                  <t indent="0" pn="section-4.1.1-2.3.2.2.1">If the match for the transmission route carries a PTA that has the LIR-pF
           flag, the leaf-tracking routes are Leaf A-D routes whose
           Route Key field is derived from the NLRI of the S-PMSI A-D
           route according to the procedures described in <xref target="RFC8534" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8534#section-5.2" derivedContent="RFC8534"/>.
                  </t>
                </li>
              </ol>
              <t indent="0" pn="section-4.1.1-2.3.3">
           Note that in both cases, SMET routes may be used in lieu of
           Leaf A-D routes, as a PE may omit the Leaf A-D route in response to
           an S-PMSI A-D route with the LIR or LIR-pF bit set if a SMET route
           with the corresponding Tag, Source, and Group fields is already
           originated <xref target="RFC9572" format="default" sectionFormat="of" derivedContent="RFC9572"/>.
           In particular, in the second case above, even though the SMET route
           does not have a PTA attached, it is still considered a Leaf A-D
           route in response to a wildcard S-PMSI A-D route with the LIR-pF bit
           set.
              </t>
            </li>
            <li pn="section-4.1.1-2.4" derivedCounter="4.">
              <t indent="0" pn="section-4.1.1-2.4.1">Otherwise, the route matched for transmission and leaf-tracking routes are
       determined as in rule <xref target="inclusive" format="counter" sectionFormat="of" derivedContent="1"/>.
              </t>
            </li>
          </ol>
          <t indent="0" pn="section-4.1.1-3">If no route is matched for transmission, the packet is not forwarded
       onto a P-tunnel. If the tunnel that the ingress determines to use
       based on the route matched for transmission (and considering
       interworking with PEs that do not support certain tunnel types
       per procedures in <xref target="RFC9251" format="default" sectionFormat="of" derivedContent="RFC9251"/>)
       requires leaf tracking (e.g., Ingress Replication, RSVP-TE P2MP tunnel,
       or BIER) but there are no leaf-tracking routes,
       the packet will not be forwarded onto a P-tunnel either.
          </t>
          <t indent="0" pn="section-4.1.1-4">The following text assumes that BIER is the determined tunnel type.
       The ingress PE pushes an upstream-assigned ESI label per <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>
       if the following conditions are all met:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.1-5">
            <li pn="section-4.1.1-5.1">
              <t indent="0" pn="section-4.1.1-5.1.1">The packet is received on a multihomed ES.
              </t>
            </li>
            <li pn="section-4.1.1-5.2">
              <t indent="0" pn="section-4.1.1-5.2.1">It is EVPN-MPLS.
              </t>
            </li>
            <li pn="section-4.1.1-5.3">
              <t indent="0" pn="section-4.1.1-5.3.1">The ESI label procedure is used for split horizon.
              </t>
            </li>
          </ul>
          <t indent="0" pn="section-4.1.1-6">The MPLS label from the PTA of the route matched
       for transmission is then pushed onto the packet's label stack for
       EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to
       the packet with the VNI/VSID set to the value in the PTA's Label field,
       and then an IP/UDP header is prepended if needed (e.g., for PHP purposes). 
          </t>
          <t indent="0" pn="section-4.1.1-7">Then, the packet is encapsulated in a BIER
       header and forwarded according to the procedures of
       <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> and <xref target="RFC8296" format="default" sectionFormat="of" derivedContent="RFC8296"/>.
       Specifically, see "Imposing and Processing
       the BIER Encapsulation" (<xref target="RFC8296" format="default" sectionFormat="of" section="3" derivedLink="https://rfc-editor.org/rfc/rfc8296#section-3" derivedContent="RFC8296"/>).      
       The Proto field in the BIER header is set to 2 in the case of EVPN-MPLS,
       7/8/9 in the case of EVPN-VXLAN/NVGRE/GENEVE (<xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 5"/>) when an IP header is not used, or 4/6 if an IP header is used
       for EVPN-VXLAN/NVGRE/GENEVE.
          </t>
          <t indent="0" pn="section-4.1.1-8">To create the proper BIER header for a given packet, the
       BFIR must know all the BFERs that need to receive that packet.
       This is determined from the set of leaf-tracking routes.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-at-a-bfir-that-is-a-p-tunne">At a BFIR That Is a P-Tunnel Segmentation Point</name>
          <t indent="0" pn="section-4.1.2-1">In this case, the encapsulation for the upstream segment of the P-tunnel
       includes (among other things) a label that identifies the x-PMSI or
       IMET A-D route that
       is the match for reception on the upstream segment. The segmentation point
       re-advertised the route into one or more downstream regions. Each
       instance of the re-advertised route for a downstream region has a PTA
       that specifies the tunnel for that region. For any particular downstream
       region, the route matched for transmission is the re-advertised route,
	   and the leaf-tracking routes are determined as follows, if needed,
       for the tunnel type:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.2-2">
            <li pn="section-4.1.2-2.1">
              <t indent="0" pn="section-4.1.2-2.1.1">If the route matched for transmission is an x-PMSI route, it must have
       the LIR flag set in its PTA, and the leaf-tracking routes are all the
       matching Leaf A-D and SMET routes received in the downstream region.
              </t>
            </li>
            <li pn="section-4.1.2-2.2">
              <t indent="0" pn="section-4.1.2-2.2.1">If the route matched for transmission is an IMET route, the leaf-tracking
       routes are all the IMET routes for the same BD received in the downstream
       region.
              </t>
            </li>
          </ul>
          <t indent="0" pn="section-4.1.2-3">If the downstream region uses BIER, the packet is forwarded as follows:
    the upstream segmentation's encapsulation is removed and the
	above-mentioned label is swapped to the
       upstream-assigned label in the PTA of the route matched for transmission,
       and then a BIER header is imposed as in <xref target="ingresspe" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>.
          </t>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-disposition">Disposition</name>
        <t indent="0" pn="section-4.2-1">The same procedures in <xref target="RFC8556" section="4.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-4.2" derivedContent="RFC8556"/>
       are followed for EVPN-MPLS, except for some EVPN specifics that are discussed in
       the following two subsections of this document.
        </t>
        <t indent="0" pn="section-4.2-2">For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the payload is
       VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
       field in the VXLAN/NVGRE/GENEVE header is used to determine the corresponding
       BD.
        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-at-a-bfer-that-is-an-egress">At a BFER That Is an Egress PE</name>
          <t indent="0" pn="section-4.2.1-1">Once the corresponding BD is determined from
       the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per
       <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> or <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> are followed.
       In the case of EVPN-MPLS, if there is an inner label in the label stack
       following the BIER header, that inner label is considered the
       upstream-assigned ESI label for split-horizon purposes.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-at-a-bfer-that-is-a-p-tunne">At a BFER That Is a P-Tunnel Segmentation Point</name>
          <t indent="0" pn="section-4.2.2-1">This is only applicable to EVPN-MPLS. The same procedures in
       <xref target="RFC8556" section="4.2.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8556#section-4.2.2" derivedContent="RFC8556"/> are followed,
       subject to multihoming procedures specified in
       <xref target="RFC9572" format="default" sectionFormat="of" derivedContent="RFC9572"/>.
          </t>
        </section>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">Per this document, IANA has registered the following three values in the
         "BIER Next Protocol Identifiers" registry:
      </t>
      <table align="center" pn="table-1">
        <name slugifiedName="name-bier-next-protocol-identifi">BIER Next Protocol Identifiers Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">7</td>
            <td align="left" colspan="1" rowspan="1">Payload is VXLAN encapsulated (no IP/UDP header)</td>
            <td align="left" colspan="1" rowspan="1">RFC 9624</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">8</td>
            <td align="left" colspan="1" rowspan="1">Payload is NVGRE encapsulated (no IP header)</td>
            <td align="left" colspan="1" rowspan="1">RFC 9624</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">9</td>
            <td align="left" colspan="1" rowspan="1">Payload is GENEVE encapsulated (no IP/UDP header)</td>
            <td align="left" colspan="1" rowspan="1">RFC 9624</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-3">IANA has also assigned an IPv4 and an IPv6 multicast
      address for the case discussed in <xref target="php-address" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.</t>
      <t indent="0" pn="section-5-4">
      The following entry has been added to the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-5-5">
        <dt pn="section-5-5.1">Address(es):</dt>
        <dd pn="section-5-5.2"> 224.0.0.122</dd>
        <dt pn="section-5-5.3">Description:</dt>
        <dd pn="section-5-5.4"> Network Virtualization Overlay (NVO) BUM Traffic</dd>
        <dt pn="section-5-5.5">Reference:</dt>
        <dd pn="section-5-5.6"> RFC 9624</dd>
      </dl>
      <t indent="0" pn="section-5-6">
The following entry has been added to the "Link-Local Scope Multicast Addresses" registry for IPv6:</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-5-7">
        <dt pn="section-5-7.1">Address(es):</dt>
        <dd pn="section-5-7.2">FF02:0:0:0:0:0:0:14</dd>
        <dt pn="section-5-7.3">Description:</dt>
        <dd pn="section-5-7.4"> Network Virtualization Overlay (NVO) BUM Traffic</dd>
        <dt pn="section-5-7.5">Reference:</dt>
        <dd pn="section-5-7.6"> RFC 9624</dd>
      </dl>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">This document is about using BIER as provider tunnels for EVPN.
	  It is very similar to using BIER as MVPN provider tunnels and
	  does not introduce additional security implications
	  beyond what have been discussed in the EVPN base protocol specification
	  <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and MVPN using BIER <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" to="CMCAST-ENHANCEMENTS"/>
    <displayreference target="I-D.ietf-bier-php" to="BIER-PHP"/>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6513" target="https://www.rfc-editor.org/info/rfc6513" quoteTitle="true" derivedAnchor="RFC6513">
          <front>
            <title>Multicast in MPLS/BGP IP VPNs</title>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6513"/>
          <seriesInfo name="DOI" value="10.17487/RFC6513"/>
        </reference>
        <reference anchor="RFC6514" target="https://www.rfc-editor.org/info/rfc6514" quoteTitle="true" derivedAnchor="RFC6514">
          <front>
            <title>BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs</title>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="T. Morin" initials="T." surname="Morin"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6514"/>
          <seriesInfo name="DOI" value="10.17487/RFC6514"/>
        </reference>
        <reference anchor="RFC6625" target="https://www.rfc-editor.org/info/rfc6625" quoteTitle="true" derivedAnchor="RFC6625">
          <front>
            <title>Wildcards in Multicast VPN Auto-Discovery Routes</title>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="W. Hendrickx" initials="W." surname="Hendrickx"/>
            <author fullname="R. Qiu" initials="R." surname="Qiu"/>
            <date month="May" year="2012"/>
            <abstract>
              <t indent="0">In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6625"/>
          <seriesInfo name="DOI" value="10.17487/RFC6625"/>
        </reference>
        <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" quoteTitle="true" derivedAnchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC7900" target="https://www.rfc-editor.org/info/rfc7900" quoteTitle="true" derivedAnchor="RFC7900">
          <front>
            <title>Extranet Multicast in BGP/IP MPLS VPNs</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="Y. Cai" initials="Y." surname="Cai"/>
            <author fullname="T. Morin" initials="T." surname="Morin"/>
            <date month="June" year="2016"/>
            <abstract>
              <t indent="0">Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7900"/>
          <seriesInfo name="DOI" value="10.17487/RFC7900"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8279" quoteTitle="true" derivedAnchor="RFC8279">
          <front>
            <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <date month="November" year="2017"/>
            <abstract>
              <t indent="0">This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8279"/>
          <seriesInfo name="DOI" value="10.17487/RFC8279"/>
        </reference>
        <reference anchor="RFC8296" target="https://www.rfc-editor.org/info/rfc8296" quoteTitle="true" derivedAnchor="RFC8296">
          <front>
            <title>Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="I. Meilik" initials="I." surname="Meilik"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8296"/>
          <seriesInfo name="DOI" value="10.17487/RFC8296"/>
        </reference>
        <reference anchor="RFC8365" target="https://www.rfc-editor.org/info/rfc8365" quoteTitle="true" derivedAnchor="RFC8365">
          <front>
            <title>A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="R. Shekhar" initials="R." surname="Shekhar"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8365"/>
          <seriesInfo name="DOI" value="10.17487/RFC8365"/>
        </reference>
        <reference anchor="RFC8534" target="https://www.rfc-editor.org/info/rfc8534" quoteTitle="true" derivedAnchor="RFC8534">
          <front>
            <title>Explicit Tracking with Wildcard Routes in Multicast VPN</title>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="J. Kotalwar" initials="J." surname="Kotalwar"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <date month="February" year="2019"/>
            <abstract>
              <t indent="0">The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8534"/>
          <seriesInfo name="DOI" value="10.17487/RFC8534"/>
        </reference>
        <reference anchor="RFC8556" target="https://www.rfc-editor.org/info/rfc8556" quoteTitle="true" derivedAnchor="RFC8556">
          <front>
            <title>Multicast VPN Using Bit Index Explicit Replication (BIER)</title>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="M. Sivakumar" initials="M." surname="Sivakumar"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8556"/>
          <seriesInfo name="DOI" value="10.17487/RFC8556"/>
        </reference>
        <reference anchor="RFC8926" target="https://www.rfc-editor.org/info/rfc8926" quoteTitle="true" derivedAnchor="RFC8926">
          <front>
            <title>Geneve: Generic Network Virtualization Encapsulation</title>
            <author fullname="J. Gross" initials="J." role="editor" surname="Gross"/>
            <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
            <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8926"/>
          <seriesInfo name="DOI" value="10.17487/RFC8926"/>
        </reference>
        <reference anchor="RFC9251" target="https://www.rfc-editor.org/info/rfc9251" quoteTitle="true" derivedAnchor="RFC9251">
          <front>
            <title>Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="S. Thoria" initials="S." surname="Thoria"/>
            <author fullname="M. Mishra" initials="M." surname="Mishra"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Lin" initials="W." surname="Lin"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9251"/>
          <seriesInfo name="DOI" value="10.17487/RFC9251"/>
        </reference>
        <reference anchor="RFC9572" target="https://www.rfc-editor.org/info/rfc9572" quoteTitle="true" derivedAnchor="RFC9572">
          <front>
            <title>Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures</title>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <author fullname="W. Lin" initials="W." surname="Lin"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <date month="May" year="2024"/>
            <abstract>
              <t indent="0">This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9572"/>
          <seriesInfo name="DOI" value="10.17487/RFC9572"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-bier-php" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-php-11" quoteTitle="true" derivedAnchor="BIER-PHP">
          <front>
            <title>BIER Penultimate Hop Popping</title>
            <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date month="February" day="6" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bier-php-11"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" target="https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-04" quoteTitle="true" derivedAnchor="CMCAST-ENHANCEMENTS">
          <front>
            <title>MVPN/EVPN C-Multicast Routes Enhancements</title>
            <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="R." surname="Kebler" fullname="Robert Kebler">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="W." surname="Lin" fullname="Wen Lin">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="E." surname="Rosen" fullname="Eric C. Rosen"> </author>
            <date month="March" day="17" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4875" target="https://www.rfc-editor.org/info/rfc4875" quoteTitle="true" derivedAnchor="RFC4875">
          <front>
            <title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
            <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
            <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
            <author fullname="S. Yasukawa" initials="S." role="editor" surname="Yasukawa"/>
            <date month="May" year="2007"/>
            <abstract>
              <t indent="0">This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.</t>
              <t indent="0">There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4875"/>
          <seriesInfo name="DOI" value="10.17487/RFC4875"/>
        </reference>
        <reference anchor="RFC6388" target="https://www.rfc-editor.org/info/rfc6388" quoteTitle="true" derivedAnchor="RFC6388">
          <front>
            <title>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="B. Thomas" initials="B." surname="Thomas"/>
            <date month="November" year="2011"/>
            <abstract>
              <t indent="0">This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6388"/>
          <seriesInfo name="DOI" value="10.17487/RFC6388"/>
        </reference>
        <reference anchor="RFC7348" target="https://www.rfc-editor.org/info/rfc7348" quoteTitle="true" derivedAnchor="RFC7348">
          <front>
            <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
            <author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/>
            <author fullname="D. Dutt" initials="D." surname="Dutt"/>
            <author fullname="K. Duda" initials="K." surname="Duda"/>
            <author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
            <author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
            <author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
            <author fullname="M. Bursell" initials="M." surname="Bursell"/>
            <author fullname="C. Wright" initials="C." surname="Wright"/>
            <date month="August" year="2014"/>
            <abstract>
              <t indent="0">This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7348"/>
          <seriesInfo name="DOI" value="10.17487/RFC7348"/>
        </reference>
        <reference anchor="RFC7637" target="https://www.rfc-editor.org/info/rfc7637" quoteTitle="true" derivedAnchor="RFC7637">
          <front>
            <title>NVGRE: Network Virtualization Using Generic Routing Encapsulation</title>
            <author fullname="P. Garg" initials="P." role="editor" surname="Garg"/>
            <author fullname="Y. Wang" initials="Y." role="editor" surname="Wang"/>
            <date month="September" year="2015"/>
            <abstract>
              <t indent="0">This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7637"/>
          <seriesInfo name="DOI" value="10.17487/RFC7637"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors thank <contact fullname="Eric Rosen"/> for his review and suggestions.
         Additionally, much of the text is borrowed verbatim from
         <xref target="RFC8556" format="default" sectionFormat="of" derivedContent="RFC8556"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>zzhang@juniper.net</email>
        </address>
      </author>
      <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>prz@juniper.net</email>
        </address>
      </author>
      <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <email>sajassi@cisco.com</email>
        </address>
      </author>
      <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>jorge.rabadan@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
