<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!--	$Id: draft-ietf-bess-evpn-irb-mcast.xml,v 1.4 2020/12/23 19:26:29 zzhang Exp $ pre-edited by ST 03/22/24 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3810 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC4360 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC6513 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC6625 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6625.xml">
<!ENTITY RFC7153 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC7716 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7716.xml">
<!ENTITY RFC7761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"> nbsp    "&#160;">
  <!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"> zwsp   "&#8203;">
  <!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9135.xml"> nbhy   "&#8209;">
  <!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml">
<!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"> wj     "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-irb-mcast-11" ipr="trust200902"> number="9625" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="6" symRefs="true" sortRefs="true" version="3">

  <front>

<!-- [rfced] Note that we have updated the short title, which appears in the
running header in the PDF output, as follows.

Original:
   evpn-irb-mcast

Current:
   EVPN OISM Forwarding
-->

    <title abbrev="evpn-irb-mcast">EVPN abbrev="EVPN OISM Forwarding">EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding</title>
    <seriesInfo name="RFC" value="9625"/>
    <author fullname="Wen Lin" initials="W." surname="Lin">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>10 Technology Park Drive</street>
          <city>Westford</city>
          <region>Massachusetts</region>
          <region>MA</region>
          <code>01886</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>10 Technology Park Drive</street>
          <city>Westford</city>
          <region>Massachusetts</region>
          <region>MA</region>
          <code>01886</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <author fullname="John Drake" initials="J." surname="Drake">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1194 N. Mathilda Ave</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <author fullname="Eric C. Rosen" initials="E." surname="Rosen" role="editor">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>10 Technology Park Drive</street>
          <city>Westford</city>
          <region>Massachusetts</region>
          <region>MA</region>
          <code>01886</code>
          <country>United States</country> States of America</country>
        </postal>
        <email> erosen52@gmail.com</email>
        <email>erosen52@gmail.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>777 E. Middlefield Road</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>sajassi@cisco.com</email>
      </address>
    </author>

    <workgroup>BESS</workgroup>
    <date month="August" year="2024"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <t>
        Ethernet VPN (EVPN) provides a service that allows a single Local
        Area Network (LAN), comprising a single IP subnet, to be divided
        into multiple "segments".  Each segment may be located at a
        different site, and the segments are interconnected by an IP or MPLS
        backbone.  Intra-subnet traffic (either unicast or multicast) always
        appears to the end users to be bridged, even when it is actually
        carried over the IP or MPLS backbone.  When a single "tenant" owns
        multiple such LANs, EVPN also allows IP unicast traffic to be routed
        between those LANs.  This document specifies new procedures that
        allow inter-subnet IP multicast traffic to be routed among the LANs
        of a given tenant, tenant while still making intra-subnet IP multicast
        traffic appear to be bridged.  These procedures can provide optimal
        routing of the inter-subnet multicast traffic, traffic and do not require
        any such traffic to egress a given router and then ingress that same
        router.  These procedures also accommodate IP multicast traffic that
        originates or is destined to be external to the EVPN domain.
      </t>
    </abstract>
    <note title="Requirements Language">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
          "MAY", and "OPTIONAL" in this document are to be interpreted as
          described in BCP 14 <xref target="RFC2119"/> <xref
          target="RFC8174"/> when, and only when, they appear in all
          capitals, as shown here.
        </t>
    </note>
  </front>
  <middle>
    <section title="Introduction" anchor="introduction"> anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <section title="Terminology" anchor="terminology"> anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
        In this document document, we make frequent use of the following terminology:
        <list style="symbols">
          <t>
            OISM: Optimized
        </t>
        <dl  newline="false" spacing="normal">
            <dt>OISM:</dt> <dd>Optimized Inter-Subnet Multicast.  EVPN&nbhy;PEs  EVPN-PEs that
            follow the procedures of this document will be known as "OISM"
            PEs.  EVPN&nbhy;PEs
            Provider Edges (PEs).  EVPN-PEs that do not follow the procedures of this
            document will be known as "non&nbhy;OISM" "non-OISM" PEs.
          </t>
          <t>
            IP
            </dd>
            <dt>IP Multicast Packet: An Packet:</dt> <dd>An IP packet whose IP Destination Address
            field is a multicast address that is not a link&nbhy;local link-local
            address.  (Link&nbhy;local  (Link-local addresses are IPv4 addresses in the
            224/24 range and IPv6 address addresses in the FF02/16 range.)
          </t>
          <t>
            IP
            </dd>
            <dt>IP Multicast Frame: An Frame:</dt> <dd>An Ethernet frame whose payload is an IP
            multicast packet (as defined above).
          </t>
          <t>
          </dd>

<!--[rfced] Per RFC 9574, should "IP Source Address" be updated to "Source
IP Address" in the following sentences?

Original:
   *  (S,G) Multicast Packet: An IP multicast packet whose IP Source
      Address field contains S and whose IP Destination Address field
      contains G.
          </t>
          <t>

   *  (S,G) Multicast Frame: An IP multicast frame whose payload
      contains S in its IP Source Address field and G in its IP
      Destination Address field.
          </t>
          <t>
			EVPN Instance (EVI):
-->

            <dt>(S,G) Multicast Packet:</dt> <dd>An IP multicast packet whose IP Source
            Address field contains S and whose IP Destination Address field
            contains G.
            </dd>
            <dt>(S,G) Multicast Frame:</dt> <dd>An IP multicast frame whose payload
            contains S in its IP Source Address field and G in its IP
            Destination Address field.
            </dd>
            <dt>EVI:</dt> <dd>EVPN Instance. An EVPN instance spanning the Provider Edge
			(PE)
	    PE devices participating in that EVPN.
          </t>
          <t>
            Broadcast Domain (BD): an
            </dd>
            <dt>BD:</dt> <dd><t>Broadcast Domain. An emulated Ethernet, such that two
            systems on the same BD will receive each other's link&nbhy;local
            broadcasts.
            <vspace/>
            <vspace/> link-local
            broadcasts.</t>
            <t>
            Note that EVPN supports service models in which a single EVPN
            Instance EVI
            contains only one BD, BD and service models in which
            a single EVI contains multiple BDs.  Both types of service model models
            are supported by this draft. document. In all models, a given BD belongs
            to only one EVI.
            </t>
          <t>
            Designated Forwarder (DF).
          </dd>
            <dt>DF:</dt> <dd><t>Designated Forwarder. As defined in <xref
            target="RFC7432"/>, target="RFC7432" format="default"/>, an Ethernet segment may be multi&nbhy;homed multihomed
            (attached to more than one PE).  An Ethernet segment may also
            contain multiple BDs, BDs of one or more EVIs.  For each such EVI,
            one of the PEs attached to the segment becomes that EVI's DF for
            that segment.  Since a BD may belong to only one EVI, we can
            speak unambiguously of the BD's DF for a given segment.
            <vspace/>
            <vspace/>
          </t>

<!--[rfced] We note that "a segment's DF" is only used in this instance
in the document. May we remove this sentence?

Original:
   When the text makes it clear that we are speaking in the context
   of a given BD, we will frequently use the term "a segment's DF" to
   mean the given BD's DF for that segment.
          </t>
-->

            <t>
            When the text makes it clear that we are speaking in the context
            of a given BD, we will frequently use the term "a segment's
            DF" to mean the given BD's DF for that segment.
            </t>
          </dd>

<!--[rfced] To clarify "router (L3) layer", may we update this sentence
as follows?

Original:
   *  AC: Attachment Circuit.  An AC connects the bridging function of
      an EVPN&nbhy;PE EVPN-PE to an Ethernet segment of a particular BD.  ACs are not
      visible at the router (L3) layer.
            <vspace/>
            <vspace/>

Perhaps:
   *  AC: Attachment Circuit.  An AC connects the bridging function of
        an EVPN-PE to an Ethernet segment of a particular BD.  ACs are not
        visible at the Layer 3 (L3) router.
-->

            <dt>AC:</dt> <dd><t>Attachment Circuit.  An AC connects the bridging function of
            an EVPN-PE to an Ethernet segment of a particular BD.  ACs
            are not visible at the router (L3) layer.
	  </t>
            <t>
            If a given Ethernet segment, attached to a given PE, contains n
            BDs, we will say that the PE has n ACs to that segment.
            </t>
          <t>
            L3 Gateway: An
          </dd>
            <dt>L3 Gateway:</dt> <dd>An L3 Gateway is a PE that connects an EVPN tenant
            domain to an external multicast domain by performing both the
            OISM procedures and the Layer 3 multicast procedures of the
            external domain.
          </t>
          <t>
            PEG (PIM/EVPN Gateway): A
            </dd>
            <dt>PEG:</dt> <dd>PIM/EVPN Gateway. An L3 Gateway that connects an EVPN
            Tenant Domain to an external multicast domain whose Layer 3
            multicast procedures are those of PIM <xref
            target="RFC7761"/>.
          </t>
          <t>
            MEG (MVPN/EVPN Gateway): A target="RFC7761" format="default"/>.
            </dd>
            <dt>MEG:</dt> <dd>MVPN/EVPN Gateway. An L3 Gateway that connects an EVPN
            Tenant Domain to an external multicast domain whose Layer 3
            multicast procedures are those of MVPN (<xref
            target="RFC6513"/>, Multicast VPN (MVPN) <xref target="RFC6514"/>).
          </t>
          <t>
            IPMG (IP target="RFC6513" format="default"/> <xref target="RFC6514" format="default"/>.
            </dd>
            <dt>IPMG:</dt> <dd>IP Multicast Gateway): Gateway. A PE that is used for interworking
            OISM EVPN&nbhy;PEs EVPN-PEs with non&nbhy;OISM EVPN&nbhy;PEs.
          </t>
          <t>
            DR (Designated Router): non-OISM EVPN-PEs.
            </dd>
            <dt>DR:</dt> <dd>Designated Router. A PE that has special responsibilities
            for handling multicast on a given BD.
          </t>
          <t>
            FHR (First
            </dd>
            <dt>FHR:</dt> <dd>First Hop Router): Router. The FHR is a PIM router <xref
            target="RFC7761"/> target="RFC7761" format="default"/> with special responsibilities.  It is the
            first multicast router to see (S,G) packets from source S, and
            if G is an "Any Source "Any-Source Multicast (ASM)" group, the FHR is
            responsible for sending PIM Register messages to the PIM
            Rendezvous Point for group G.
          </t>
          <t>
            LHR (Last
            </dd>
            <dt>LHR:</dt> <dd>Last Hop Router): Router. The LHR is a PIM router <xref
            target="RFC7761"/> target="RFC7761" format="default"/> with special responsibilities.  Generally, it
            is attached to a LAN, and it determines whether there are any
            hosts on the LAN that need to receive a given multicast flow.
            If so, it creates and sends the PIM Join messages that are
            necessary to receive the flow.
          </t>
          <t>
            EC (Extended Community).
            </dd>
            <dt>EC:</dt>  <dd>Extended Community. A BGP Extended Communities attribute
            (<xref target="RFC4360"/>,
            <xref target="RFC7153"/>) target="RFC4360" format="default"/> <xref target="RFC7153" format="default"/> is a BGP
            path attribute that consists of one or more extended
            communities.
          </t>
          <t>
            RT (Route Target): Extended
            Communities.
            </dd>
            <dt>RT:</dt> <dd>Route Target. A Route Target is a particular kind of BGP
            Extended Community.  A BGP Extended Community consists of a type
            field, a sub-type field, and a value field.  Certain
            type/sub-type combinations indicate that a particular Extended
            Community is an RT.  RT1 and RT2 are considered to be the same
            RT if and only if they have the same type, same sub-type, and
            same
            value fields.
          </t>
          <t>
            Use of the "C&nbhy;" prefix.  In
            </dd>
            <dt>"C-" prefix:</dt>  <dd>In many documents on VPN
            multicast, the prefix "C&nbhy;" "C-" appears before any address or
            wildcard that refers to an address or addresses in a tenant's
            address space, space rather than to an address of addresses in the
            address space of the backbone network.  This document omits the
            "C&nbhy;"
            "C-" prefix in many cases where it is clear from the
            context that the reference is to the tenant's address space.
          </t>
       </list>
      </t>
            </dd>
        </dl>
        <t>
        This document also assumes familiarity with the terminology of <xref
        target="RFC4364"/>, target="RFC4364" format="default"/>, <xref target="RFC6514"/>, target="RFC6514" format="default"/>, <xref
        target="RFC7432"/>, target="RFC7432" format="default"/>, <xref target="RFC7761"/>, target="RFC7761" format="default"/>, <xref
        target="RFC9251"/>, target="RFC9136" format="default"/>, <xref target="RFC9136"/> target="RFC9251" format="default"/>, and <xref
        target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. target="RFC9572" format="default"/>.
        </t>
	<section>
      <name>Requirements Language</name>
              <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
              </t>
	</section>
      </section>
      <!-- terminology -->

      <section title="Background" anchor="background"> anchor="background" numbered="true" toc="default">
        <name>Background</name>
        <t>
          Ethernet VPN (EVPN) <xref target="RFC7432"/> target="RFC7432" format="default"/> provides a Layer 2
          VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer
          Ethernet service to a set of customers, known as "tenants".
        </t>
        <t>
          In this section (as well as in <xref target="RFC9135"/>), target="RFC9135" format="default"/>), we
          provide some essential background information on EVPN.
        </t>
        <section title="Segments, anchor="intro_bd" numbered="true" toc="default">
          <name>Segments, Broadcast Domains, and Tenants"
                 anchor="intro_bd"> Tenants</name>
          <t>
            One of the key concepts of EVPN is the Broadcast Domain (BD).  A
            BD is essentially an emulated Ethernet.  Each BD belongs to a
            single tenant.  A BD typically consists of multiple Ethernet
            "segments", and each segment may be attached to a different EVPN
            Provider Edge (EVPN&nbhy;PE) (EVPN-PE) router.  EVPN&nbhy;PE  EVPN-PE routers are
            often referred to as "Network Virtualization Endpoints" or NVEs. Endpoints (NVEs)".
            However, this document will use the term "EVPN&nbhy;PE", "EVPN-PE" or,
            when the context is clear, just "PE".
          </t>
          <t>
            In this document, the term "segment" is used interchangeable interchangeably with
			the
			"Ethernet Segment" or "ES" "ES", as defined in <xref target="RFC7432"/>. target="RFC7432" format="default"/>.
          </t>
          <t>
            Attached to each segment are "Tenant Systems" (TSes). Systems (TSs)".  A TS may
            be any type of system, physical or virtual, host or router,
            etc., that can attach to an Ethernet.
          </t>
          <t>
            When two TSes TSs are on the same segment, traffic between them does
            not pass through an EVPN&nbhy;PE. EVPN-PE.  When two TSes TSs are on
            different segments of the same BD, traffic between them does
            pass through an EVPN&nbhy;PE. EVPN-PE.
          </t>
          <t>
            When two TSes, TSs, say TS1 and TS2 TS2, are on the same BD, then:
            <list style="symbols"> then the following occurs:
          </t>
          <ul spacing="normal">
            <li>
              <t>
                If TS1 knows the MAC Media Access Control (MAC) address of TS2, TS1 can send unicast
                Ethernet frames to TS2.  TS2 will receive the frames
                unaltered.
              </t>
            </li>
            <li>
              <t>
                If TS1 broadcasts an Ethernet frame, TS2 will receive the
                unaltered frame.
              </t>
            </li>
            <li>
              <t>
                If TS1 multicasts an Ethernet frame, TS2 will receive the
                unaltered frame, frame as long as TS2 has been provisioned to
                receive the Ethernet multicast destination MAC address.
              </t>
            </list>
          </t>
            </li>
          </ul>
          <t>
            When we say that TS2 receives an unaltered frame from TS1, we
            mean that the frame still contains TS1's MAC address, address and that
            no alteration of the frame's payload (and consequently, no
            alteration of the payload's IP header) has been made.
          </t>
          <t>
            EVPN allows a single segment to be attached to multiple PE
            routers.  This is known as "EVPN multi&nbhy;homing". multihoming". Suppose a
            given segment is attached to both PE1 and PE2, and suppose PE1
            receives a frame from that segment.  It may be necessary for PE1
            to send the frame over the backbone to PE2.  EVPN has procedures
            to ensure that such a frame cannot be sent by PE2 back to its
            originating segment. segment by PE2.  This is particularly important for
            multicast, because a frame arriving at PE1 from a given segment
            will already have been seen by all the systems on that segment
            that need to see it. If the frame were was sent back to the
            originating segment by PE2, receivers on that segment would
            receive the packet twice. Even worse, the frame might be sent
            back to PE1, which could cause an infinite loop.
          </t>
        </section>
        <!-- intro_bd -->
        <section title="Inter-BD anchor="inter_bd" numbered="true" toc="default">
          <name>Inter-BD (Inter-Subnet) IP Traffic"
                 anchor="inter_bd"> Traffic</name>
          <t>
            If a given tenant has multiple BDs, the tenant may wish to allow
            IP communication among these BDs.  Such a set of BDs is known as
            an "EVPN Tenant Domain" or just a "Tenant Domain".
          </t>
          <t>
            If tenant systems TS1 and TS2 are not in the same BD, then they
            do not receive unaltered Ethernet frames from each other.  In
            order for TS1 to send traffic to TS2, TS1 encapsulates an IP
            datagram inside an Ethernet frame, frame and uses Ethernet to send
            these frames to an IP router.  The router decapsulates the IP
            datagram, does the IP processing processing, and re-encapsulates the
            datagram for Ethernet.  The MAC source address Source Address field now has the
            MAC address of the router, not of TS1. The TTL field of the IP
            datagram should be decremented by exactly 1, even if the frame
            needs to be sent from one PE to another.  The structure of the
            provider's backbone is thus hidden from the tenants.
          </t>
          <t>
            EVPN accommodates the need for inter&nbhy;BD inter-BD communication
            within a Tenant Domain by providing an integrated L2/L3 service
            for unicast IP traffic.  EVPN's Integrated Routing and Bridging
            (IRB) functionality is specified in <xref target="RFC9135"/>. target="RFC9135" format="default"/>.
            Each BD in a Tenant Domain is assumed to be a single IP subnet,
            and each IP subnet within a given Tenant Domain is assumed to
            be a single BD.  EVPN's IRB functionality allows IP traffic to
            travel from one BD to another, another and ensures that proper IP
            processing (e.g., TTL decrement) is done.
          </t>
          <t>
            A brief overview of IRB, including the notion of an "IRB
            interface", can be found in <xref target="irb"/>. target="irb" format="default"/>.  As explained
            there, an IRB interface is a sort of virtual interface
            connecting an L3 routing instance to a BD.  A BD may have
            multiple attachment circuits Attachment Circuits (ACs) to a given PE, where each AC
            connects to a different Ethernet segment of the BD.  However,
            these ACs are not visible to the L3 routing function; from the
            perspective of an L3 routing instance, a PE has just one
            interface to each BD, viz., the IRB interface for that BD.
          </t>
          <t>
			In this document, when traffic is routed out of an IRB interface,
			we say it is sent down the IRB interface to the BD that the IRB is
			for. In the other direction, traffic is sent up the IRB interface
			from the BD to the L3 routing instance.
          </t>
          <t>
            The "L3 routing instance" depicted in <xref target="irb"/> target="irb" format="default"/> is
            associated with a single Tenant Domain, Domain and may be thought of as
            an IP&nbhy;VRF
            IP Virtual Routing and Forwarding (IP-VRF) for that Tenant Domain.
          </t>
        </section>
        <!-- inter_bd -->
        <section title="EVPN anchor="evpn_ip_mcast" numbered="true" toc="default">
          <name>EVPN and IP Multicast"
                 anchor="evpn_ip_mcast"> Multicast</name>
          <t>
            <xref target="RFC9135"/> target="RFC9135" format="default"/> and <xref target="RFC9136"/> target="RFC9136" format="default"/>
            cover inter&nbhy;subnet (inter&nbhy;BD) inter-subnet (inter-BD) IP unicast forwarding,
            but they do not cover inter&nbhy;subnet inter-subnet IP multicast forwarding.
          </t>
          <t>
            <xref target="RFC7432"/>

<!--[rfced] RFC 7432 does not include any instances of "intra-subnet"
but does include "inter-subnet". Please review and let us know if
this citation is correct or if updates are needed to the
sentences below.

Original:
   [RFC7432] covers intra&nbhy;subnet
            (intra&nbhy;BD) intra-subnet (intra-BD) Ethernet multicast.  The intra&nbhy;subnet
   intra-subnet Ethernet multicast procedures of <xref target="RFC7432"/> [RFC7432] are used for
   Ethernet Broadcast traffic, for Ethernet unicast traffic whose MAC
   Destination Address field contains an Unknown address, and for
   Ethernet traffic whose MAC Destination Address field contains an
   Ethernet Multicast MAC address.

   ...
   Rather, standard EVPN intra-subnet procedures (as detailed in [RFC7432])
   are used to deliver the frame to PE2, which then sends it to H4.
-->

          <t>
            <xref target="RFC7432" format="default"/> covers intra-subnet
            (intra-BD) Ethernet multicast.  The intra-subnet
            Ethernet multicast procedures of <xref target="RFC7432" format="default"/> are
            used for Ethernet broadcast traffic, Ethernet unicast
            traffic whose MAC Destination Address field contains an unknown
            address, and Ethernet traffic whose MAC Destination Address
            field contains an Ethernet multicast MAC address.  These three
            classes of traffic are known collectively as "BUM traffic"
            (Broadcast/Unknown-Unicast/Multicast),
            (Broadcast, Unknown Unicast, or Multicast traffic), and the procedures for
            handling BUM traffic are known as "BUM procedures".
          </t>
          <t>
            <xref target="RFC9251"/> target="RFC9251" format="default"/> extends the intra&nbhy;subnet intra-subnet
            Ethernet multicast procedures by adding procedures that are
            specific to, and optimized for, the use of IP multicast within a
            subnet.  However, that document does not cover inter&nbhy;subnet inter-subnet
            IP multicast.
          </t>
          <t>
            The purpose of this document is to specify procedures for EVPN
            that provide optimized IP multicast functionality within an EVPN
            tenant domain.  This document also specifies procedures that
            allow IP multicast packets to be sourced from or destined to
            systems outside the Tenant Domain. We refer to the The entire set of
            these
            procedures are referred to as "OISM" (Optimized Inter&nbhy;Subnet
            Multicast) "Optimized Inter-Subnet
            Multicast (OISM)" procedures.
          </t>
          <t>
            In order to support the OISM procedures specified in this
            document, an EVPN&nbhy;PE MUST EVPN-PE <bcp14>MUST</bcp14> also support <xref
            target="RFC9135"/> target="RFC9135" format="default"/> and <xref target="RFC9251"/>. target="RFC9251" format="default"/>.  (However,
            certain procedures in <xref target="RFC9251"/> target="RFC9251" format="default"/> are
            modified when OISM is supported.)
          </t>
        </section>
        <!-- "evpn_ip_mcast -->

        <section title="BDs, MAC-VRFS, anchor="evpn_stuff" numbered="true" toc="default">
          <name>BDs, MAC-VRFs, and EVPN Service Models"
                 anchor="evpn_stuff"> Models</name>
          <t>
          <xref target="RFC7432"/> target="RFC7432" format="default"/> defines the notion of "MAC&nbhy;VRF". "MAC-VRF" (MAC Virtual Routing and Forwarding).
            A MAC&nbhy;VRF MAC-VRF contains one or more "Bridge Tables" "bridge tables" (see section
            3 of
            <xref target="RFC7432"/> for a discussion of this
            terminology), target="RFC7432" format="default" sectionFormat="of" section="3"/>), each of which represents a single Broadcast
            Domain.
          </t>
          <t>
            In the IRB model (outlined in <xref target="irb"/>), target="irb" format="default"/>), an L3 routing
            instance has one IRB interface per BD, NOT one per MAC&nbhy;VRF. MAC-VRF.
            This document does not distinguish between a "Broadcast Domain"
            and a "Bridge Table", and will use "bridge table"; instead, it uses the terms interchangeably (or
            will use the acronym "BD" to refer to either).  The way the BDs
            are grouped into MAC&nbhy;VRFs MAC-VRFs is not relevant to the procedures
            specified in this document.
          </t>
          <t>
            Section 6 of
            <xref target="RFC7432"/> target="RFC7432" format="default" sectionFormat="of" section="6"/> also defines several
            different EVPN service models:
            <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
                In the "vlan&nbhy;based "vlan-based service", each MAC&nbhy;VRF MAC-VRF contains
                one "bridge table", where the bridge table corresponds to a
                particular Virtual LAN (VLAN). (See section 3 of (VLAN) (see <xref
                target="RFC7432"/> for a discussion of this terminology.) target="RFC7432" format="default" sectionFormat="of" section="3"/>).
                Thus, each VLAN is treated as a BD.
              </t>
            </li>
            <li>
              <t>
                In the "vlan bundle service", each MAC&nbhy;VRF MAC-VRF contains one
                bridge table, where the bridge table corresponds to a set of
                VLANs.  Thus  Thus, a set of VLANs are treated as constituting a
                single BD.
              </t>
            </li>
            <li>
              <t>
                In the "vlan&nbhy;aware "vlan-aware bundle service", each MAC&nbhy;VRF MAC-VRF
                may contain multiple bridge tables, where each bridge table
                corresponds to one BD.  If a MAC&nbhy;VRF MAC-VRF contains several
                bridge tables, then it corresponds to several BDs.
              </t>
            </list>
          </t>
            </li>
          </ul>
          <t>
            The procedures in this document are intended to work for all
            these service models.
          </t>
        </section>
        <!-- evpn_stuff -->
      </section>
      <!-- background -->

      <section title="Need anchor="need" numbered="true" toc="default">
        <name>Need for EVPN-aware EVPN-Aware Multicast Procedures" anchor="need"> Procedures</name>
        <t>
          Inter&nbhy;subnet
          Inter-subnet IP multicast among a set of BDs can be achieved,
          in a non&nbhy;optimal non-optimal manner, without any specific EVPN
          procedures.  For instance, if a particular tenant has n BDs among
          which he wants to send IP multicast traffic, he can simply attach
          a conventional multicast router to all n BDs.  Or more generally,
          as long as each BD has at least one IP multicast router, and the
          IP multicast routers communicate multicast control information
          with each other, conventional IP multicast procedures will work
          normally, and no special EVPN functionality is needed.
        </t>
        <t>
          However, that technique does not provide optimal routing for
          multicast.  In conventional multicast routing, for a given
          multicast flow, there is only one multicast router on each BD that
          is permitted to send traffic of that flow to the BD.  If that BD
          has receivers for a given flow, but the source of the flow is not
          on that BD, then the flow must pass through that multicast router.
          This leads to the "hair&nbhy;pinning" "hairpinning" problem described (for
          unicast) in <xref target="irb"/>. target="irb" format="default"/>.
        </t>
        <t>
          For example, consider an (S,G) flow that is sourced by a TS S and
          needs to be received by TSes TSs R1 and R2.  Suppose S is on a segment
          of BD1, R1 is on a segment of BD2, but both are attached to PE1.
          Suppose also
          Also suppose that the tenant has a multicast router, router attached to a
          segment of BD1 and to a segment of BD2.  However, the segments to
          which that router is attached are both attached to PE2.  Then  Then, the
          flow from S to R would have to follow the path:
          S-->PE1-->PE2-->Tenant&nbsp;Multicast&nbsp;Router-->PE2-->PE1-->R1.
          S--&gt;PE1--&gt;PE2--&gt;Tenant Multicast Router--&gt;PE2--&gt;PE1--&gt;R1.
          Obviously, the path S-->PE1-->R S--&gt;PE1--&gt;R would be preferred.
        </t>

      <figure align="center">
        <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                 +---+                      +---+
                 |PE1+----------------------+PE2|
                 +---+-+                  +-+---+
                  | \   \                /  / |
                 BD1 BD2 BD3          BD3 BD2 BD1
                  |   |   |              \  | |
                  S  R1   R2             router

        </artwork>
      </figure>
        ]]></artwork>
        <t>
          Now suppose that there is a second receiver, R2.  R2 is attached
          to a third BD, BD3.  However, it is attached to a segment of BD3
          that is attached to PE1.  And suppose also that the Tenant
          Multicast Router is attached to a segment of BD3 that attaches to
          PE2.  In this case, the Tenant Multicast Router will make two
          copies of the packet, one for BD2 and one for BD3.  PE2 will send
          both copies back to PE1.  Not only is the routing sub-optimal, but
          also
          PE2 also sends multiple copies of the same packet to PE1.  This PE1, which is a
          further sub-optimality.
        </t>
        <t>
          This is only an example; many more examples of sub-optimal
          multicast routing can easily be given.  To eliminate sub-optimal
          routing and extra copies, it is necessary to have a multicast
          solution that is EVPN-aware, EVPN-aware and that can use its knowledge of the
          internal structure of a Tenant Domain to ensure that multicast
          traffic gets routed optimally. The procedures in this document
          allow us to avoid all such sub-optimalities when routing
          inter&nbhy;subnet
          inter-subnet multicast traffic within a Tenant Domain.
        </t>
      </section>
      <section title="Additional anchor="requirements" numbered="true" toc="default">
        <name>Additional Requirements That Must be Be Met by the Solution"
               anchor="requirements"> Solution</name>
        <t>
          In addition to providing optimal routing of multicast flows within a
          Tenant Domain, the EVPN-aware multicast solution is intended to
          satisfy the following requirements:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
              The solution must integrate well with the procedures specified
              in <xref target="RFC9251"/>. target="RFC9251" format="default"/>. That is, an integrated set of
              procedures must handle both intra&nbhy;subnet intra-subnet multicast and
              inter&nbhy;subnet
              inter-subnet multicast.
            </t>
          </li>
          <li>
            <t>
              With regard to intra&nbhy;subnet intra-subnet multicast, the solution MUST <bcp14>MUST</bcp14>
              maintain the integrity of the multicast Ethernet service.  This
              means:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>
                  If a source and a receiver are on the same subnet, the MAC
                  source address
                  Source Address (SA) of the multicast frame sent by the
                  source will not get rewritten.
                </t>
              </li>
              <li>
                <t>
                  If a source and a receiver are on the same subnet, no IP
                  processing of the Ethernet payload is done.  The IP TTL is
                  not decremented, the IPv4 header checksum is not changed, no
                  fragmentation is done, etc.
                </t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>
              On the other hand, if a source and a receiver are on different
              subnets, the frame received by the receiver will not have the
              MAC Source address Address of the source, as the frame will appear to
              have come from a multicast router.  Also, proper processing of
              the IP header is done, e.g., TTL decrement decrements by 1, header
              checksum modification, possible fragmentation, etc.
            </t>
          </li>
          <li>
            <t>
              If a Tenant Domain contains several BDs, it MUST <bcp14>MUST</bcp14> be possible
              for a multicast flow (even when the multicast group address is
              an "any source multicast" (ASM) address), "Any-Source Multicast (ASM)" address) to have sources in
              one of those BDs and receivers in one or more of the other
              BDs,
              BDs without requiring the presence of any system performing
              PIM Rendezvous Point (RP) functions <xref
              target="RFC7761"/>. target="RFC7761" format="default"/>.
            </t>
          </li>
          <li>
            <t>
              Sometimes a MAC address used by one TS on a particular BD is
              also used by another TS on a different BD.  Inter&nbhy;subnet  Inter-subnet
              routing of multicast traffic MUST NOT <bcp14>MUST NOT</bcp14> make any assumptions
              about the uniqueness of a MAC address across several BDs.
            </t>
          </li>
          <li>
            <t>
              If two EVPN&nbhy;PEs EVPN-PEs attached to the same Tenant Domain both
              support the OISM procedures, each may receive
              inter&nbhy;subnet
              inter-subnet multicasts from the other, even if the
              egress PE is not attached to any segment of the BD from which
              the multicast packets are being sourced.  It MUST NOT <bcp14>MUST NOT</bcp14> be
              necessary to provision the egress PE with knowledge of the
              ingress BD.
            </t>
          </li>
          <li>
            <t>
              There must be a procedure that allows EVPN&nbhy;PE EVPN-PE
              routers supporting OISM procedures to send/receive multicast
              traffic to/from EVPN&nbhy;PE EVPN-PE routers that support only <xref
              target="RFC7432"/>, target="RFC7432" format="default"/> but that do does not support the OISM
              procedures or even the procedures of <xref
              target="RFC9135"/>. target="RFC9135" format="default"/>.  However, when interworking with such
              routers (which we call "non&nbhy;OISM "non-OISM PE routers"), optimal
              routing may not be achievable.
            </t>
          </li>
          <li>
            <t>
              It MUST <bcp14>MUST</bcp14> be possible to support scenarios in which multicast
              flows with sources inside a Tenant Domain have "external"
              receivers, i.e., receivers that are outside the domain.  It
              must also be possible to support scenarios where multicast
              flows with external sources (sources outside the Tenant
              Domain) have receivers inside the domain.
              <vspace/>
              <vspace/>
            </t>
            <t>
              This presupposes that unicast routes to multicast sources
              outside the domain can be distributed to EVPN&nbhy;PEs EVPN-PEs
              attached to the domain, domain and that unicast routes to multicast
              sources within the domain can be distributed outside the
              domain.
              <vspace/>
              <vspace/>
            </t>
            <t>
              Of particular importance is are the scenario scenarios in which the
              external sources and/or receivers are reachable via
              L3VPN/MVPN, and the scenario in which external sources and/or
              receivers are reachable
              L3VPN/MVPN or via IP/PIM.
              <vspace/>
              <vspace/>
            </t>
            <t>
              The solution for external interworking MUST <bcp14>MUST</bcp14> allow for
              deployment scenarios in which EVPN does not need to export a
              host route for every multicast source.
            </t>
          </li>
          <li>
            <t>
              The solution for external interworking must not presuppose
              that the same tunneling technology is used within both the
              EVPN domain and the external domain.  For example, MVPN
              interworking must be possible when MVPN is using MPLS P2MP
              tunneling, Point-to-Multipoint (P2MP)
              tunneling and when EVPN is using Ingress Replication (IR) or VXLAN Virtual eXtensible Local Area Network (VXLAN)
              tunneling.
            </t>
          </li>
          <li>
            <t>
              The solution must not be overly dependent on the details of a
              small set of use cases, cases but must be adaptable to new use cases
              as they arise.  (That is, the solution must be robust.)
            </t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section title="Model anchor="model_overview" numbered="true" toc="default">
        <name>Model of Operation: Overview" anchor="model_overview"> Overview</name>
        <section title="Control Plane" anchor="cp_overview"> anchor="cp_overview" numbered="true" toc="default">
          <name>Control Plane</name>
          <t>
          In this section, and in the remainder of this document, we assume
          the reader is familiar with the procedures of IGMP/MLD IGMP / Multicast Listener Discovery (MLD) (see <xref
          target="RFC3376"/> target="RFC3376" format="default"/> and <xref target="RFC3810"/>), target="RFC3810" format="default"/>), by which hosts
          announce their interest in receiving particular multicast flows.
          </t>
          <t>
          Consider a Tenant Domain consisting of a set of k BDs:
          BD1,&nbsp;...,&nbsp;BDk.
          BD1, ..., BDk.  To support the OISM procedures, each
          Tenant Domain must also be associated with a "Supplementary
          Broadcast Domain" (SBD). Domain (SBD)".  An SBD is treated in the control plane
          as a real BD, but it does not have any ACs.  The SBD has several
          uses; these will be described later in this document (see Sections <xref
          target="sbd_intro"/> target="sbd_intro" format="counter"/> and <xref target="solution"/>). target="solution" format="counter"/>).
          </t>
          <t>
          Each PE that attaches to one or more of the BDs in a given tenant
          domain will be provisioned to recognize that those BDs are part of
          the same Tenant Domain.  Note that a given PE does not need to be
          configured with all the BDs of a given Tenant Domain.  In general,
          a PE will only be attached to a subset of the BDs in a given
          Tenant Domain, Domain and will be configured only with that subset of
          BDs.  However, each PE attached to a given Tenant Domain must be
          configured with the SBD for that Tenant Domain.
          </t>
          <t>
          Suppose a particular segment of a particular BD is attached to
          PE1. <xref target="RFC7432"/> target="RFC7432" format="default"/> specifies that PE1 must originate an
          Inclusive Multicast Ethernet Tag (IMET) route for that BD, BD and
          that the IMET route must be propagated to all other PEs attached
          to the same BD.  If the given segment contains a host that has
          interest in receiving a particular multicast flow, either an (S,G)
          flow or a (*,G) flow, PE1 will learn of that interest by
		  participating in the IGMP/MLD snooping procedures,
		  as specified in <xref target="RFC4541"/>. target="RFC4541" format="default"/>.  In this case:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
              PE1 is interested in receiving the flow;
              </t>
            </li>
            <li>
              <t>
              The
              the AC attaching the interested host to PE1 is also said to be
              interested in the flow; and
              </t>
            </li>
            <li>
              <t>
              The
              the BD containing an AC that is interested in a particular
              flow is also said to be interested in that flow.
              </t>
          </list>
        </t>
            </li>
          </ul>
          <t>
          Once PE1 determines that it has an AC that is interested in
          receiving a particular flow or set of flows, it originates one or
          more Selective Multicast Ethernet Tag (SMET) route(s) routes
		  <xref target="RFC9251"/> target="RFC9251" format="default"/> to advertise that interest.
          </t>
          <t>
          Note that each IMET or SMET route is "for" a particular BD.  The
          notion of a route being "for" a particular BD is explained in
          <xref target="bd_route"/>. target="bd_route" format="default"/>.
          </t>
          <t>
          When OISM is being supported, the procedures of <xref
          target="RFC9251"/>, target="RFC9251" format="default"/> are modified as follows:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
              The IMET route originated by a particular PE for a particular
              BD is distributed to all other PEs attached to the Tenant
              Domain containing that BD, even to those PEs that are not
              attached to that particular BD.
              </t>
            </li>
            <li>
              <t>
              The SMET routes originated by a particular PE are originated
              on a per-Tenant-Domain basis, basis rather than on a per-BD basis.
              That is, the SMET routes are considered to be for the Tenant
              Domain's SBD, SBD rather than for any of its ordinary BDs. These
              SMET routes are distributed to all the PEs attached to the
              Tenant Domain.
              <vspace/>
              <vspace/>
              </t>
              <t>
              In this way, each PE attached to a given Tenant Domain learns,
              from each the other PE PEs attached to the same Tenant Domain, the set
              of flows that are of interest to each of those other PEs.
              </t>
          </list>
        </t>
            </li>
          </ul>
          <!-- <t> -->
        <!--   OISM PEs MUST <bcp14>MUST</bcp14> follow the procedures of <xref -->
        <!--   target="RFC9251"/>.  (Though see Sections <xref -->
        <!--   target="smet_adv" format="counter"/> and <xref target="external" -->
        <!--   format="counter"/> for an exception.)  In this document, we extend -->
        <!--   the procedures of <xref target="RFC9251"/> so that IMET and -->
        <!--   SMET routes for a particular BD are distributed not just to PEs -->
        <!--   that attach to that BD, but to PEs that attach to any BD in the -->
        <!--   Tenant Domain. -->
        <!-- </t> -->
        <!-- <t> -->
        <!--   Note that if some PE attached to the Tenant Domain does not -->
        <!--   support <xref target="RFC9251"/>, it will be assumed to be -->
        <!--   interested in all flows.  Whether a particular remote PE supports -->
        <!--   <xref target="RFC9251"/> is determined by the presence of an -->
        <!--   "EVPN Multicast Flags Extended Community" attached to its IMET -->
        <!--   routes; this is specified in <xref target="RFC9251"/>.   -->
        <!-- </t> -->
        <t>
          An OISM PE that is provisioned with several BDs in the same Tenant
          Domain MUST <bcp14>MUST</bcp14> originate an IMET route for each such BD.  To indicate
          its support of <xref target="RFC9251"/>, target="RFC9251" format="default"/>, it SHOULD <bcp14>SHOULD</bcp14> attach the
          EVPN Multicast Flags Extended Community
          <!-- (with the RFC9251 flag -->
          <!-- set) -->
          to each such IMET route, but it MUST <bcp14>MUST</bcp14> attach the EC
          <!-- (with the -->
          <!-- RFC9251 flag set) -->
          to at least one such IMET route.
          </t>
          <t>

<!--[rfced] To avoid redundancy with "is provisioned", we updated this
sentence as shown below. Please let us know if this still
captures the intended meaning or if you prefer otherwise.

Original:
   Suppose PE1 is provisioned with both BD1 and BD2, BD2 and is provisioned
   to consider them to be part of the same Tenant Domain.

Current:
   Suppose PE1 is provisioned with both BD1 and BD2 and considers
   them to be part of the same Tenant Domain.
-->

          Suppose PE1 is provisioned with both BD1 and BD2 and
          considers them to be part of the same Tenant Domain.
          It is possible that PE1 will receive from PE2 both an IMET route
          for BD1 and an IMET route for BD2. BD2 from PE2.  If either of these IMET routes
          has the EVPN Multicast Flags Extended Community, PE1 MUST <bcp14>MUST</bcp14> assume
          that PE2 is supporting the procedures of <xref
          target="RFC9251"/> target="RFC9251" format="default"/> for ALL BDs in the Tenant Domain.
          </t>
<!-- IANA flag: OISM-supported flag -->
          <t>
          If a PE supports OISM functionality, it indicates that that, by setting
          the "OISM-supported" OISM-supported flag in the Multicast Flags Extended
          Community that
          Community, it attaches to some or all of its IMET routes. An
          OISM PE SHOULD <bcp14>SHOULD</bcp14> attach this EC with the OISM-supported flag set to
          all the IMET routes it originates.  However, if PE1 imports IMET
          routes from PE2, and at least one of PE2's IMET routes indicates
          that PE2 is an OISM PE, PE1 MUST <bcp14>MUST</bcp14> assume that PE2 is following OISM
          procedures.
          </t>
        </section>
        <!-- control plane overview -->
      <section title="Data Plane" anchor="dp_overview"> anchor="dp_overview" numbered="true" toc="default">
          <name>Data Plane</name>
          <t>
          Suppose PE1 has an AC to a segment in BD1, BD1 and PE1 receives from
          that AC an (S,G) multicast frame  from
          that AC (as defined in <xref
          target="terminology"/>). target="terminology" format="default"/>).
          </t>
          <t>
          There may be other ACs of PE1 on which TSes TSs have indicated an
          interest (via IGMP/MLD) in receiving (S,G) multicast packets.  PE1
          is responsible for sending the received multicast packet on those
          ACs.  There are two cases to consider:
          <list style="symbols">
          </t>

<!--[rfced] As "AC" is expanded as "Attachment Circuit", may we remove
"attachment" from this sentence? (If expanded, "attachment AC" would read
as "attachment Attachment Circuit".)

Original:
   *  Intra-Subnet Forwarding: In this case, an attachment AC with
      interest in (S,G) is connected to a segment that is part of the
      source BD, BD1.

Perhaps:
   *  Intra-Subnet Forwarding: In this case, an AC with
      interest in (S,G) is connected to a segment that is part of the
      source BD, BD1.
-->

          <ul spacing="normal">
            <li>
              <t>
              Intra-Subnet Forwarding: In this case, an attachment AC with
              interest in (S,G) is connected to a segment that is part of
              the source BD, BD1.  If the segment is not multi&nbhy;homed, multihomed,
              or if PE1 is the Designated Forwarder (DF) (see <xref
              target="RFC7432"/>) target="RFC7432" format="default"/>) for that segment, PE1 sends the multicast
              frame on that AC without changing the MAC SA. The IP header is
              not modified at all; in particular, the TTL is not
              decremented.
              </t>
            </li>
            <li>
              <t>
              Inter-Subnet Forwarding: An AC with interest in (S,G) is
              connected to a segment of BD2, where BD2 is different than
              BD1.  If PE1 is the DF for that segment (or if the segment is
              not multi&nbhy;homed), multihomed), PE1 decapsulates the IP multicast
              packet, performs any necessary IP processing (including TTL
              decrement), and then re-encapsulates the packet appropriately for
              BD2.  PE1 then sends the packet on the AC.  Note that after
              re-encapsulation, the MAC SA will be PE1's MAC address on BD2.
              The IP TTL will have been decremented by 1.
              </t>
          </list>
        </t>
            </li>
          </ul>
          <t>
          In addition, there may be other PEs that are interested in (S,G)
          traffic.  Suppose PE2 is such a PE.  Then  Then, PE1 tunnels a copy of
          the IP multicast frame (with its original MAC SA, SA and with no
          alteration of the payload's IP header) to PE2. The tunnel
          encapsulation contains information that PE2 can use to associate
          the frame with an "apparent source BD".  If the actual source BD
          of the frame is BD1, then:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
              If PE2 is attached to BD1, the tunnel encapsulation used to
              send the frame to PE2 will cause PE2 to identify BD1 as the
              apparent source BD.
              </t>
            </li>
            <li>
              <t>
              If PE2 is not attached to BD1, the tunnel encapsulation used
              to send the frame to PE2 will cause PE2 to identify the SBD as
              the apparent source BD.
              </t>
          </list>
        </t>
            </li>
          </ul>
          <t>
          Note that the tunnel encapsulation used for a particular BD
          will have been advertised in an IMET route or S&nbhy;PMSI a Selective
          Provider Multicast Service Interface (S-PMSI) route <xref
          target="I-D.ietf-bess-evpn-bum-procedure-updates"/>
          target="RFC9572" format="default"/> for that BD.  That route
          carries a PMSI Tunnel attribute, Attribute, which specifies how packets
          originating from that BD are encapsulated. This information
          enables the PE receiving a tunneled packet to identify the
          apparent source BD as stated above. See <xref target="adv_tunnels"/>
          target="adv_tunnels" format="default"/> for more details.
          </t>
          <t>
          When PE2 receives the tunneled frame, it will forward it on any of
          its ACs that have interest in (S,G).
          </t>
          <t>
         If PE2 determines from the tunnel encapsulation that the apparent
         source BD is BD1, then
         <list style="symbols"> then:
          </t>
          <ul spacing="normal">
            <li>
              <t>
              For those ACs that connect PE2 to BD1, the intra&nbhy;subnet intra-subnet
              forwarding procedure described above is used, except that it
              is now PE2, not PE1, carrying out that procedure.  Unmodified
              EVPN procedures from <xref target="RFC7432"/> target="RFC7432" format="default"/> are used to
              ensure that a packet originating from a multi&nbhy;homed multihomed
              segment is never sent back to that segment.
              </t>
            </li>
            <li>
              <t>
             For those ACs that do not connect to BD1, the inter&nbhy;subnet inter-subnet
             forwarding procedure described above is used, except that it is
             now PE2, not PE1, carrying out that procedure.
              </t>
         </list>
        </t>
            </li>
          </ul>
          <t>
          If the tunnel encapsulation identifies the apparent source BD as
          the SBD, PE2 applies the inter&nbhy;subnet inter-subnet forwarding procedures
          described above to all of its ACs that have interest in the flow.
          </t>
          <t>
         These procedures ensure that an IP multicast frame travels from its
         ingress PE to all egress PEs that are interested in receiving
         it. While in transit, the frame retains its original MAC SA, and
         the payload of the frame retains its original IP header.  Note that
         in all cases, when an IP multicast packet is sent from one BD to
         another, these procedures cause its TTL to be decremented by 1.
          </t>
          <t>
         So far far, we have assumed that an IP multicast packet arrives at its
         ingress PE over an AC that belongs to one of the BDs in a given
         Tenant Domain.  However, it is possible for a packet to arrive at
         its ingress PE in other ways.  Since an EVPN&nbhy;PE EVPN-PE supporting IRB
         has an IP&nbhy;VRF, IP-VRF, it is possible that the IP&nbhy;VRF IP-VRF will have a
         "VRF interface" that is not an IRB interface.  For example, there
         might be a VRF interface that is actually a physical link to an
         external Ethernet switch, or to a directly attached host, or to a
         router.  When an EVPN&nbhy;PE, EVPN-PE, say PE1, receives a packet through
         such means, we will say that the packet has an "external" source
         (i.e., a source "outside the Tenant Domain").  There are also other
         scenarios in which a multicast packet might have an external
         source, e.g., it might arrive over an MVPN tunnel from an L3VPN
         PE. In such cases, we will still refer to PE1 as the "ingress
         EVPN&nbhy;PE".
         EVPN-PE".
          </t>
          <t>
         When an EVPN&nbhy;PE, EVPN-PE, say PE1, receives an externally sourced
         multicast packet, and there are receivers for that packet inside
         the Tenant Domain, it does the following:
         <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
             Suppose PE1 has an AC in BD1 that has interest in (S,G).  Then  Then,
             PE1 encapsulates the packet for BD1, filling in the MAC SA
             field with PE1's own MAC address on BD1.  It sends the
             resulting frame on the AC.
              </t>
            </li>
            <li>
              <t>
             Suppose some other EVPN&nbhy;PE, EVPN-PE, say PE2, has interest in
             (S,G).  PE1 encapsulates the packet for Ethernet, filling in
             the MAC SA field with PE1's own MAC address on the SBD. PE1
             then tunnels the packet to PE2.  The tunnel encapsulation will
             identify the apparent source BD as the SBD.  Since the apparent
             source BD is the SBD, PE2 will know to treat the frame as an
             inter&nbhy;subnet
             inter-subnet multicast.
              </t>
         </list>
       </t>
            </li>
          </ul>
          <t>
         When ingress replication Ingress Replication is used to transmit IP multicast frames
         from an ingress EVPN&nbhy;PE EVPN-PE to a set of egress PEs, then
         the ingress PE has to send multiple copies of the frame.  Each copy
         is the original Ethernet frame; decapsulation and IP processing
         take place only at the egress PE.
          </t>
          <t>
          If a Point-to-Multipoint (P2MP) tree or BIER Bit Index Explicit Replication (BIER) <xref
          target="I-D.ietf-bier-evpn"/> target="I-D.ietf-bier-evpn" format="default"/> is used to transmit an IP multicast frame
          from an ingress PE to a set of egress PEs, then the ingress PE
          only has to send one copy of the frame to each of its next hops.
          Again, each egress PE receives the original frame and does any
          necessary IP processing.
          </t>
        </section>
        <!-- dp_overview -->
    </section>
      <!-- model_overview -->
  </section>
    <!-- Introduction -->

    <section title="Detailed anchor="model_detail" numbered="true" toc="default">
      <name>Detailed Model of Operation"
             anchor="model_detail"> Operation</name>
      <t>
        The model described in <xref target="dp_overview"/> target="dp_overview" format="default"/> can be expressed
        more precisely using the notion of "IRB interface" (see <xref
        target="irb"/>). target="irb" format="default"/>).  For a given Tenant Domain:
        <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>
            A given PE has one IRB interface for each BD to which it is attached.
            This IRB interface connects L3 routing to that BD.  When
            IP multicast packets are sent or received on the IRB interfaces,
            the semantics of the interface is are modified from the semantics
            described in <xref target="irb"/>. target="irb" format="default"/>.  See <xref
            target="ingress_irb_use"/> target="ingress_irb_use" format="default"/> for the details of the modification.
          </t>
        </li>
        <li>
          <t>
            Each PE also has an IRB interface that connects L3 routing to
            the SBD. The semantics of this interface is different than the
            semantics of the IRB interface to the real BDs. See <xref
            target="ingress_irb_use"/>.
          </t>
        </list> target="ingress_irb_use" format="default"/>.
          </t>
        </li>
      </ul>
      <t>
        In this section section, we assume that PIM is not enabled on the IRB
        interfaces.  In general, it is not necessary to enable PIM on the
        IRB interfaces unless there are PIM routers on one of the Tenant
        Domain's BDs, BDs or unless there is some other scenario requiring a
        Tenant Domain's L3 routing instance to become a PIM adjacency of
        some other system.  These cases will be discussed in <xref
        target="pim"/>. target="pim" format="default"/>.
      </t>
      <section title="Supplementary anchor="sbd_intro" numbered="true" toc="default">
        <name>Supplementary Broadcast Domain" anchor="sbd_intro"> Domain</name>
        <t>
        Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3) and
        two PEs (PE1, (PE1 and PE2).  PE1 attaches to BD1 and BD2, while PE2 attaches
        to BD2 and BD3.
        </t>
        <t>
        To carry out the procedures described above, all the PEs attached to
        the Tenant Domain must be provisioned with the SBD for that tenant
        domain. A Route Target (RT) must be associated with the SBD, SBD and
        provisioned on each of those PEs.  We will refer to that RT as the
        "SBD&nbhy;RT".
        "SBD-RT".
        </t>
        <t>
        A Tenant Domain is also configured with an IP&nbhy;VRF IP-VRF <xref
        target="RFC9135"/>, target="RFC9135" format="default"/>, and the IP&nbhy;VRF IP-VRF is associated with an RT.
        This RT MAY <bcp14>MAY</bcp14> be the same as the SBD&nbhy;RT. SBD-RT.
        </t>
        <t>
        Suppose an (S,G) multicast frame originating on BD1 has a receiver
        on BD3.  PE1 will transmit the packet to PE2 as a frame, and the
        encapsulation will identify the frame's source BD as BD1.  Since PE2
        is not provisioned with BD1, it will treat the packet as if its
        source BD were the SBD.  That is, a packet can be transmitted from
        BD1 to BD3 even though its ingress PE is not configured for BD3, BD3
        and/or its egress PE is not configured for BD1.
        </t>
        <t>
        EVPN supports service models in which a given EVPN Instance (EVI)
        can contain only one BD.  It also supports service models in which a
        given EVI can contain multiple BDs.  No matter which service model
        is being used for a particular tenant, it is highly RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
        an EVI containing only the SBD be provisioned for that tenant.
        </t>
        <t>
        If, for some reason, it is not feasible to provision an EVI that
        contains only the SBD, it is possible to put the SBD in an EVI that
        contains other BDs.  However, in that case, the SBD&nbhy;RT MUST SBD-RT <bcp14>MUST</bcp14> be
        different than the RT associated with any other BD.  Otherwise  Otherwise, the
        procedures of this document (as detailed in Sections <xref target="bd_route" format="counter"/> and <xref target="sbd_rts" format="counter"/>) will not produce correct results.
        </t>
      </section>
      <!-- sbd -->

    <section title="Detecting anchor="bd_route" numbered="true" toc="default">
        <name>Detecting When a Route is For/From for/from a Particular BD"
             anchor="bd_route"> BD</name>
        <t>
        In this document, we frequently say that a particular multicast
        route is "from" a particular BD, or is "for" a particular BD, BD or is "related to" a particular BD, or "is
        associated
        "associated with" a particular BD.  These terms are used
        interchangeably.  Subsequent sections of this document explain when
        various routes must be originated for particular BDs.  In this
        section, we explain how the PE originating a route marks the route
        to indicate which BD it is for.  We also explain how a PE
        receiving the route determines which BD the route is for.
        </t>
        <t>
        In EVPN, each BD is assigned a Route Target (RT).  An RT is a BGP
        extended community
        Extended Community that can be attached to the BGP routes used by
        the EVPN control plane.  In some EVPN service models, each BD is
        assigned a unique RT.  In other service models, a set of BDs (all in
        the same EVI) may be assigned the same RT.  The RT that is assigned
        to the SBD is called the "SBD&nbhy;RT". "SBD-RT".
        </t>
        <t>
        In those service models that allow a set of BDs to share a single
        RT, each BD is assigned a non&nbhy;zero non-zero Tag ID.  The Tag ID appears
        in the Network Layer Reachability Information (NLRI) of many of the
        BGP routes that are used by the EVPN control plane.
        </t>
        <t>
        A given route may be for the SBD, SBD or for an "ordinary BD" (a BD
        that is not the SBD).  An RT that has been assigned to an ordinary
        BD will be known as an "ordinary BD&nbhy;RT". BD-RT".
        </t>
        <t>
        When constructing an IMET, SMET, S&nbhy;PMSI, S-PMSI, or Leaf <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/> target="RFC9572" format="default"/> route that is for a given BD,
        the following rules apply:
        <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
            If the route is for an ordinary BD, say BD1, then
            <list style="symbols"> then:
            </t>
            <ul spacing="normal">
              <li>
                <t>
                the route MUST <bcp14>MUST</bcp14> carry the ordinary BD&nbhy;RT BD-RT associated with
                BD1,
                BD1 and
                </t>
              </li>
              <li>
                <t>
                the route MUST NOT <bcp14>MUST NOT</bcp14> carry any RT that is associated with an
                ordinary BD other than BD1.
                </t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>
            If the route is for the SBD, the route MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT, SBD-RT
            and MUST NOT <bcp14>MUST NOT</bcp14> carry any RT that is associated with any other BD.
            </t>
          </li>
          <li>
            <t>
            As detailed in subsequent sections, under certain circumstances circumstances,
            a route that is for BD1 may carry both the RT of BD1 and also
            the SBD&nbhy;RT.
          </t>
        </list> SBD-RT.
            </t>
          </li>
        </ul>
<!-- IANA flag: OISM SBD flag -->
        <t>The IMET route for the SBD MUST <bcp14>MUST</bcp14> carry a Multicast Flags Extended
         Community,
         Community in which an "OISM SBD" OISM SBD flag is set.
        </t>
        <t>The IMET route for a BD other than the SBD SHOULD <bcp14>SHOULD</bcp14> carry an EVI-RT EC
         as defined in <xref target="RFC9251"/>. target="RFC9251" format="default"/>. The EC is constructed
         from the SBD&nbhy;RT, SBD-RT to indicate the BD's corresponding SBD.
         This allows all PEs to check that they have consistent SBD provisioning
         and allow allows an Assisted Replication (AR) replicator to automatically
         determine a BD's corresponding SBD without any provisioning, as explained in
         <xref target="SBD-matching"/>. target="SBD-matching" format="default"/>.
        </t>
        <t>
        When receiving an IMET, SMET, S&nbhy;PMSI, S-PMSI, or Leaf route, it is necessary
        for the receiving PE to determine the BD to which the route belongs.
        This is done by examining the RTs carried by the route, as well as
        the Tag ID field of the route's NLRI.  There are several cases to
        consider.  Some of these cases are error cases that arise when the
        route has not been properly constructed.
        </t>
        <t>
        When one of the error cases is detected, the route MUST <bcp14>MUST</bcp14> be regarded
        as a malformed route, and the "treat-as-withdraw" procedure of <xref
        target="RFC7606"/> MUST target="RFC7606" format="default"/> <bcp14>MUST</bcp14> be applied.  Note that these error
        cases are only detectable by EVPN procedures at the receiving PE;
        BGP procedures at intermediate nodes will generally not detect the
        existence of such error cases, cases and in general SHOULD NOT <bcp14>SHOULD NOT</bcp14> attempt to
        do so.
        </t>
      <t>
        <list style="format Case %d:">
        <ol spacing="normal" type="Case %d:"><li>
            <t>
            The receiving PE recognizes more than one of the route's RTs as
            being an SBD&nbhy;RT SBD-RT (i.e., the route carries SBD&nbhy;RTs SBD-RTs of
            more than one Tenant Domain).
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is an error case; the route has not been properly
            constructed.
            </t>
          </li>
          <li>
            <t>
            The receiving PE recognizes one of the route's RTs as being
            associated with an ordinary BD, BD and recognizes one of the
            route's other RTs as being associated with a different ordinary
            BD.
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is an error case; the route has not been properly
            constructed.
            </t>
          </li>
          <li>
            <t>
            The receiving PE recognizes one of the route's RTs as being
            associated with an ordinary BD in a particular Tenant Domain, Domain
            and recognizes another of the route's RTs as being associated
            with the SBD of a different Tenant Domain.
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is an error case; the route has not been properly
            constructed.
            </t>
          </li>
          <li>
            <t>
            The receiving PE does not recognize any of the route's RTs as
            being associated with an ordinary BD in any of its tenant
            domains,
            domains but does recognize one of the RTs as the SBD&nbhy;RT SBD-RT
            of one of its Tenant Domains.
            <vspace/>
            <vspace/>
            </t>
            <t>
            In this case, the receiving PE associates the route with the SBD of
            that Tenant Domain. This association is made even if the Tag ID
            field of the route's NLRI is not the Tag ID of the SBD.
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is a normal use case where either (a) the route is for a BD
            to which the receiving PE is not attached, attached or (b) the route is
            for the SBD.  In either case, the receiving PE associates the
            route with the SBD.
            </t>
          </li>
          <li>
            <t>
            The receiving PE recognizes exactly one of the RTs as an
            ordinary BD&nbhy;RT BD-RT that is associated with one of the PE's
            EVIs, say EVI&nbhy;1. EVI-1.  The receiving PE also recognizes one of
            the RTs as being the SBD&nbhy;RT SBD-RT of the Tenant Domain containing
            EVI&nbhy;1.
            <vspace/>
            <vspace/>
            EVI-1.
            </t>
            <t>
            In this case, the route is associated with the BD in EVI&nbhy;1 EVI-1
            that is identified (in the context of EVI&nbhy;1) EVI-1) by the Tag ID
            field of the route's NLRI.  (If EVI&nbhy;1 EVI-1 contains only a
            single BD, the Tag ID is likely to be zero.)
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is the case where the route is for a BD to which the
            receiving PE is attached, but the route also carries the
            SBD&nbhy;RT.
            SBD-RT.  In this case, the receiving PE associates the route
            with the ordinary BD, not with the SBD.
            </t>
        </list>
      </t>
          </li>
        </ol>
<!-- [rfced] Please review whether any of the notes, including those prefaced
with "NB", in this document should be in the <aside> element. It is defined
as "a container for content that is semantically less important or tangential
to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
        <t>
        N.B.:
        NB: According to the above rules, the mapping from BD to RT is a
        many-to-one or one-to-one mapping.  A route that an EVPN&nbhy;PE EVPN-PE
        originates for a particular BD carries that BD's RT, and an
        EVPN&nbhy;PE
        EVPN-PE that receives the route associates it with a BD as
        described above.  However, RTs are not used only to help identify
        the BD to which a route belongs; they may also be used by BGP to
        determine the path along which the route is distributed, distributed and to
        determine which PEs receive the route.  There may be cases where it
        is desirable to originate a route for a particular BD, BD  but have
        that route distributed to only some of the EVPN&nbhy;PEs EVPN-PEs attached to
        that BD.  Or one might want the route distributed to some
        intermediate set of systems, where it might be modified or replaced
        before being propagated further.  Such situations are outside the
        scope of this document.
        </t>
        <t>
        Additionally, there may be situations where it is desirable to
        exchange routes among two or more different Tenant Domains ("EVPN
        Extranet").  Such situations are outside the scope of this document.
        </t>
        <!-- <t> -->
      <!--   A route is for a particular BD if it carries the RT that has been -->
      <!--   assigned to that BD, and its NLRI contains the Tag ID that has been -->
      <!--   assigned to that BD. -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   Note that a route that is for a particular BD may also carry -->
      <!--   additional RTs. -->
      <!-- </t> -->
    </section>
      <section title="Use anchor="ingress_irb_use" numbered="true" toc="default">
        <name>Use of IRB Interfaces at Ingress PE"
             anchor="ingress_irb_use"> PE</name>
        <t>
        When an (S,G) multicast frame is received from an AC belonging to a
        particular BD, say BD1:
        <list style="format %d.">
          <t
        </t>
        <ol spacing="normal" type="1"><li anchor="inter-PE">
            <t>
            The frame is sent unchanged to other EVPN&nbhy;PEs EVPN-PEs that are
            interested in (S,G) traffic.  The encapsulation used to send the
            frame to the other EVPN&nbhy;PEs EVPN-PEs depends on the tunnel type
            being used for multicast transmission. (For our purposes, we
            consider Ingress Replication (IR), Assisted Replication (AR) (AR), and
            BIER to be "tunnel types", even though IR, AR AR, and BIER do not
            actually use P2MP tunnels.)  At the egress PE, the apparent
            source BD of the frame can be inferred from the tunnel
            encapsulation.  If the egress PE is not attached to the actual
            source BD, it will infer that the apparent source BD is the SBD.
            <vspace/>
            <vspace/>
            </t>
            <t>
            Note that the the inter&nbhy;PE inter-PE transmission of a multicast
            frame among EVPN&nbhy;PEs EVPN-PEs of the same Tenant Domain does NOT
            involve the IRB interfaces, interfaces as long as the multicast frame was
            received over an AC attached to one of the Tenant Domain's BDs.
            </t>
          <t
          </li>
          <li anchor="up_IRB">
            <t>
            The frame is also sent up the IRB interface that attaches BD1 to
            the Tenant Domain's L3 routing instance in this PE.  That is,
            the L3 routing instance, behaving as if it were a multicast
            router, receives the IP multicast frames that arrive at the PE
            from its local ACs.  The L3 routing instance decapsulates the
            frame's payload to extract the IP multicast packet, decrements
            the IP TTL, adjusts the header checksum, and does any other
            necessary IP processing (e.g., fragmentation).
            </t>
          <t
          </li>
          <li anchor="down_IRB">
            <t>
            The L3 routing instance keeps track of which BDs have local
            receivers for (S,G) traffic.  (A "local receiver" is a TS,
            reachable via a local AC, that has expressed interest in (S,G)
            traffic.)  If the L3 routing instance has an IRB interface to
            BD2, and it knows that BD2 has a LOCAL receiver interested in
            (S,G) traffic, it encapsulates the packet in an Ethernet header
            for BD2, putting its own MAC address in the MAC SA field.  Then  Then,
            it sends the packet down the IRB interface to BD2.
            </t>
        </list>
      </t>
          </li>
        </ol>
        <t>
        If a packet is sent from the L3 routing instance to a particular
        BD via the IRB interface (step <xref target="down_IRB" format="counter"/> in the above list), and if the BD in question is
        NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD.  If
        the packet needs to go to other PEs, it has already been sent to
        them in step <xref target="inter-PE" format="counter"/>. Note that
        this is a change in the IRB interface semantics from what is
        described in <xref target="RFC9135"/> target="RFC9135" format="default"/> and <xref target="IRB"/>. target="IRB" format="default"/>.
        </t>
        <t>
        If a given locally attached segment is multi-homed, multihomed, existing EVPN
        procedures ensure that a packet is not sent by a given PE to that
        segment unless the PE is the DF for that segment. Those procedures
        also ensure that a packet is never sent by a PE to its segment of
        origin.  Thus  Thus, EVPN segment multi-homing multihoming is fully supported;
        duplicate delivery to a segment or looping on a segment are thereby
        prevented,
        prevented without the need for any new procedures to be defined in
        this document.
        </t>
        <t>
        What if an IP multicast packet is received from outside the tenant
        domain?  For instance, perhaps PE1's IP&nbhy;VRF IP-VRF for a particular
        tenant domain also has a physical interface leading to an external
        switch, host, or router, router and PE1 receives an IP multicast packet or
        frame on that interface. Or interface, or perhaps the packet is from an L3VPN, L3VPN or
        a different EVPN Tenant Domain.
        </t>
        <t>
        Such a packet is first processed by the L3 routing instance, which
        decrements TTL and does any other necessary IP processing.  Then  Then, the
        packet is sent into the Tenant Domain by sending it down the IRB
        interface to the SBD of that Tenant Domain.  This requires
        encapsulating the packet in an Ethernet header.  The MAC SA field
        will contain the PE's own MAC on the SBD.
        </t>
        <t>
        An IP multicast packet sent by the L3 routing instance down the IRB
        interface to the SBD is treated as if it had arrived from a local
        AC, and steps <xref target="inter-PE" format="counter"/>&nbhy;<xref format="counter"/>-<xref target="down_IRB" format="counter"/> are applied.  Note that the
        semantics of sending a packet down the IRB interface to the SBD are
        thus slightly different than the semantics of sending a packet down
        other IRB interfaces.  IP multicast packets sent down the SBD's IRB
        interface may be distributed to other PEs, but IP multicast packets
        sent down other IRB interfaces are distributed only to local ACs.
        </t>
        <t>
        If a PE sends a link&nbhy;local link-local multicast packet down the SBD IRB
        interface, that packet will be distributed (as an Ethernet frame) to
        other PEs of the Tenant Domain, Domain but will not appear on any of the
        actual BDs.
        </t>
      </section>
      <!-- ingress_irb_use -->
    <section title="Use anchor="egress_irb_use" numbered="true" toc="default">
        <name>Use of IRB Interfaces at an Egress PE"
             anchor="egress_irb_use"> PE</name>
        <t>
        Suppose an egress EVPN&nbhy;PE EVPN-PE receives an (S,G) multicast frame
        from the frame's ingress EVPN&nbhy;PE. EVPN-PE.  As described above, the
        packet will arrive as an Ethernet frame over a tunnel from the
        ingress PE, and the tunnel encapsulation will identify the source BD
        of the Ethernet frame.
        </t>
        <t>
        We define the notion of the frame's "apparent source BD" as follows.
        If the egress PE is attached to the actual source BD, the actual
        source BD is the apparent source BD.  If the egress PE is not
        attached to the actual source BD, the SBD is the apparent source BD.
        </t>
        <t>
        The egress PE now takes the following steps:
        <list style="format %d.">
        </t>
        <ol spacing="normal" type="1"><li>
            <t>
            If the egress PE has ACs belonging to the apparent source BD of
            the frame, it sends the frame unchanged to any ACs of that BD
            that have interest in (S,G) packets.  The MAC SA of the frame is
            not modified, and the IP header of the frame's payload is not
            modified in any way.
            </t>
          </li>
          <li>
            <t>
            The frame is also sent to the L3 routing instance by being sent
            up the IRB interface that attaches the L3 routing instance to
            the apparent source BD.  Steps <xref target="up_IRB" format="counter"/> and <xref target="down_IRB" format="counter"/> of listed in <xref target="ingress_irb_use"/> target="ingress_irb_use" format="default"/> are then
            applied.
            </t>
        </list>
      </t>
          </li>
        </ol>
      </section>
      <!-- egress_irb_use -->
    <section title="Announcing anchor="interest" numbered="true" toc="default">
        <name>Announcing Interest in (S,G)" anchor="interest"> (S,G)</name>
        <t>
        <xref target="RFC9251"/> target="RFC9251" format="default"/> defines procedures used by an egress PE
        to announce its interest in a multicast flow or set of flows.  If an
        egress PE determines it has LOCAL receivers in a particular BD, say
        BD1, that are interested in a particular set of flows, it originates
        one or more SMET routes for BD1.  Each SMET route specifies a
        particular (S,G) or (*,G) flow.  By originating an a SMET route for
        BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in
        BD1".  Such an a SMET route carries the Route Target (RT) for BD1,
        ensuring that it will be distributed to all PEs that are attached to
        BD1.
        </t>
        <t>
        The OISM procedures for originating SMET routes differ slightly from
        those in <xref target="RFC9251"/>. target="RFC9251" format="default"/>.  In most cases, the SMET
        routes are considered to be for the SBD, SBD rather than for the BD
        containing local receivers.  These SMET routes carry the
        SBD&nbhy;RT,
        SBD-RT and do not carry any ordinary BD-RT.  Details on the
        processing of SMET routes can be found in <xref target="smet_adv"/>. target="smet_adv" format="default"/>.
        </t>
        <t>
        Since the SMET routes carry the SBD-RT, every ingress PE attached to
        a particular Tenant Domain will learn of all other PEs (attached to
        the same Tenant Domain) that have interest in a particular set of
        flows. Note that a PE that receives a given SMET route does not
        necessarily have any BDs (other than the SBD) in common with the PE
        that originates that SMET route.
        </t>
        <t>
        If all the sources and receivers for a given (*,G) are in the Tenant
        Domain, inter&nbhy;subnet "Any Source inter-subnet "Any-Source Multicast" traffic will be
        properly routed without requiring any Rendezvous Points, shared
        trees, or other complex aspects of multicast routing infrastructure.
        Suppose, for example, that:
        <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
            PE1 has a local receiver, on BD1, for (*,G) and
            </t>
          </li>
          <li>
            <t>
            PE2 has a local source, on BD2, for (*,G).
            </t>
        </list>
      </t>
          </li>
        </ul>
        <t>
        PE1 will originate an a SMET(*,G) route for the SBD, and PE2 will
        receive that route, even if PE2 is not attached to BD1.  PE2 will
        thus know to forward (S,G) traffic to PE1.  PE1 does not need to do
        any "source discovery".  (This does assume that source S does not
        send the same (S,G) datagram on two different BDs, BDs and that the
        Tenant Domain does not contain two or more sources with the same IP
        address S.  The use of multicast sources that have IP "anycast"
        addresses is outside the scope of this document.)
        </t>
        <t>
        If some PE attached to the Tenant Domain does not support
        [RFC9251],
        <xref target="RFC9251"/>, it will be assumed to be interested in all flows.
        Whether a particular remote PE supports [RFC9251] <xref target="RFC9251"/> or not is determined
        by the presence of the Multicast Flags Extended Community
        <!-- (and the -->
        <!-- setting of the "IGMP Proxy" flag within the EC) -->
        in its IMET route;
        this is specified in [RFC9251]. <xref target="RFC9251"/>.
        </t>
      </section>
      <!-- interest -->
    <section title="Tunneling anchor="tunneling" numbered="true" toc="default">
      <name>Tunneling Frames from Ingress PE PEs to Egress PEs"
             anchor="tunneling"> PEs</name>

<!--[rfced] We note that "BUM tunnel" does not appear in RFC 7432.  Please
review and let us know if/how this citation may be updated.

Original:
   [RFC7432] specifies the procedures for setting up and using "BUM
   tunnels".

   ...
   For inclusive tunnels, there is a choice between using a BD's
   ordinary "BUM tunnel" [RFC7432] as the default inclusive tunnel for
   carrying IP multicast traffic, or using a separate IP multicast
   tunnel as the default inclusive tunnel for carrying IP multicast.
-->

        <t>
        <xref target="RFC7432"/> target="RFC7432" format="default"/> specifies the procedures for setting up and
        using "BUM tunnels".  A BUM tunnel is a tunnel used to carry traffic
        on a particular BD if that traffic is (a) broadcast traffic, or (b)
        unicast traffic with an unknown MAC DA, Destination Address (DA), or (c) Ethernet multicast
        traffic.
        </t>
        <t>
        This document allows the BUM tunnels to be used as the default
        tunnels for transmitting IP multicast frames.  It also allows a
        separate set of tunnels to be used, instead of the BUM tunnels, as
        the default tunnels for carrying IP multicast frames.  Let's call
        these "IP Multicast Tunnels".
        </t>
        <t>
        When the tunneling is done via Ingress Replication or via BIER, this
        difference is of no significance.  However, when P2MP tunnels are
        used, there is a significant advantage to having separate IP
        multicast tunnels.
        </t>

<!--[rfced] It is unclear what "Other things" refers to in this sentence.
How may it be updated for clarity?

Original:
   Other things being equal, it is desirable for an ingress PE to
   transmit a copy of a given (S,G) multicast frame on only one P2MP
   tunnel.
-->

        <t>
        Other things being equal, it is desirable for an ingress PE to
        transmit a copy of a given (S,G) multicast frame on only one P2MP
        tunnel.  All egress PEs interested in (S,G) packets then have to
        join that tunnel. If the source BD and PE for an (S,G) frame are
        BD1 and PE1 PE1, respectively, and if PE2 has receivers on BD2 for (S,G),
        then PE2 must join the P2MP LSP Label Switched Path (LSP) on which PE1 transmits the (S,G)
        frame.  PE2 must join this P2MP LSP even if PE2 is not attached to
        the source BD (BD1). BD, BD1.  If PE1 were was transmitting the multicast frame
        on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM
        tunnel, even though PE2 has no BD1 attachment circuits. Attachment Circuits.  This would
        cause PE2 to pull all the BUM traffic from BD1, most of which it
        would just have to discard.  Thus  Thus, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the default IP
        multicast tunnels be distinct from the BUM tunnels.
        </t>
        <t>
        Notwithstanding the above, link-local IP multicast traffic MUST <bcp14>MUST</bcp14>
        always be carried on the BUM tunnels, tunnels and ONLY on the BUM tunnels.
        link-local
        Link-local IP multicast traffic consists of IPv4 traffic with a
        destination address prefix of 224/24 and IPv6 traffic with a
        destination address prefix of FF02/16.  In this document, the terms
        "IP multicast packet" and "IP multicast frame" are defined in <xref
        target="terminology"/> target="terminology" format="default"/> so as to exclude link&nbhy;local link-local traffic.
        </t>
        <t>
        Note that it is also possible to use "selective tunnels" to carry
        particular multicast flows (see <xref target="adv_tunnels"/>). target="adv_tunnels" format="default"/>).  When
        an (S,G) frame is transmitted on a selective tunnel, it is not
        transmitted on the BUM tunnel or on the default IP Multicast tunnel.
        </t>
      </section>
      <!-- tunneling -->
    <section title="Advanced Scenarios" anchor="adv_scen"> anchor="adv_scen" numbered="true" toc="default">
        <name>Advanced Scenarios</name>
        <t>
        There are some deployment scenarios that require special
        procedures:
        <!-- These are discussed in detail in <xref -->
        <!-- target="advanced"/>. These scenarios are: -->
        <list style="format %d.">
        </t>
        <ol spacing="normal" type="1"><li>
            <t>
            Some multicast sources or receivers are attached to PEs that
            support <xref target="RFC7432"/>, target="RFC7432" format="default"/> but do not support this
            document or <xref target="RFC9135"/>. target="RFC9135" format="default"/>.  To interoperate with
            these "non&nbhy;OISM "non-OISM PEs", it is necessary to have one or more
            gateway PEs that interface the tunnels discussed in this
            document with the BUM tunnels of the legacy PEs.  This is
            discussed in <xref target="no-OISM"/>. target="no-OISM" format="default"/>.
            </t>
          </li>
          <li>
            <t>
            Sometimes multicast traffic originates from outside the EVPN
            domain,
            domain or needs to be sent outside the EVPN domain.  This is
            discussed in <xref target="external"/>. target="external" format="default"/>.  An important special case
            of this, integration with MVPN, is discussed in <xref
            target="mvpn"/>. target="mvpn" format="default"/>.
            </t>
          </li>
          <li>
            <t>
            In some scenarios, one or more of the tenant systems is a PIM
            router, and the Tenant Domain is used as a transit network
            that is part of a larger multicast domain.  This is discussed in

            <xref target="pim"/>.
          </t>
        </list> target="pim" format="default"/>.
            </t>
          </li>
        </ol>
      </section>
      <!-- adv_scen -->

  </section>
    <!-- model_detail -->

  <section title="EVPN-aware anchor="solution" numbered="true" toc="default">
      <name>EVPN-Aware Multicast Solution Control Plane"
           anchor="solution"> Plane</name>
      <section title="Supplementary anchor="sbd_rts" numbered="true" toc="default">
        <name>Supplementary Broadcast Domain (SBD) and Route Targets"
             anchor="sbd_rts"> Targets</name>
        <t>
          As discussed in <xref target="sbd_intro"/>, target="sbd_intro" format="default"/>, every Tenant Domain is
          associated with a single Supplementary Broadcast Domain
          (SBD). Recall that a Tenant Domain is defined to be a set of BDs
          that can freely send and receive IP multicast traffic to/from each
          other. If an EVPN&nbhy;PE EVPN-PE has one or more ACs in a BD of a
          particular Tenant Domain, and if the EVPN&nbhy;PE EVPN-PE supports the
          procedures of this document, that EVPN&nbhy;PE MUST EVPN-PE <bcp14>MUST</bcp14> be provisioned
          with the SBD of that Tenant Domain.
        </t>
        <t>
          At each EVPN&nbhy;PE EVPN-PE attached to a given Tenant Domain, there is
          an IRB interface leading from the L3 routing instance of that
          Tenant Domain to the SBD.  However, the SBD has no ACs.
        </t>
        <t>
          Each SBD is provisioned with a Route Target (RT).  All the
          EVPN&nbhy;PEs
          EVPN-PEs supporting a given SBD are provisioned with that RT
          as an import RT.  That RT MUST NOT <bcp14>MUST NOT</bcp14> be the same as the RT
          associated with any other BD.
        </t>
        <t>
          We will use the term "SBD&nbhy;RT" "SBD-RT" to denote the RT that has been
          assigned to the SBD.  Routes carrying this RT will be propagated
          to all EVPN&nbhy;PEs EVPN-PEs in the same Tenant Domain as the originator.
        </t>
        <t>
          <xref target="bd_route"/> target="bd_route" format="default"/> specifies the rules by which an
          EVPN&nbhy;PE
          EVPN-PE that receives a route determines whether a received
          route "belongs to" a particular ordinary BD or SBD.
        </t>
        <t>
          <xref target="bd_route"/> target="bd_route" format="default"/> also specifies additional rules that
          must be followed when constructing routes that belong to a
          particular BD, including the SBD.
        </t>
        <t>
          The SBD SHOULD <bcp14>SHOULD</bcp14> be in an EVPN Instance (EVI) EVI of its own. Even if
          the SBD is not in an EVI of its own, the SBD&nbhy;RT MUST SBD-RT <bcp14>MUST</bcp14> be
          different than the RT associated with any other BD.  This
          restriction is necessary in order for the rules of Sections <xref target="bd_route" format="counter"/> and <xref target="sbd_rts" format="counter"/> to work correctly.
        </t>
        <t>
          Note that an SBD, just like any other BD, is associated on each
          EVPN&nbhy;PE
          EVPN-PE with a MAC&nbhy;VRF. MAC-VRF.  Per <xref target="RFC7432"/>, target="RFC7432" format="default"/>,
          each MAC&nbhy;VRF MAC-VRF is associated with a Route Distinguisher (RD).
          When constructing a route that is "for" an SBD, an EVPN&nbhy;PE EVPN-PE
          will place the RD of the associated MAC&nbhy;VRF MAC-VRF in the "Route
          Distinguisher" Route
          Distinguisher field of the NLRI.  (If the Tenant Domain has
          several MAC&nbhy;VRFs MAC-VRFs on a given PE, the EVPN&nbhy;PE EVPN-PE has a choice
          of which RD to use.)
        </t>
        <t>
          If Assisted Replication (AR, see (AR) <xref target="I-D.ietf-bess-evpn-optimized-ir"/>) target="RFC9574" format="default"/> is
          used, each AR&nbhy;REPLICATOR AR-REPLICATOR for a given Tenant Domain must be
          provisioned with the SBD of that Tenant Domain, even if the
          AR&nbhy;REPLICATOR
          AR-REPLICATOR does not have any L3 routing instance. instances.
        </t>
      </section>
      <!-- sbd_rts -->

      <section title="Advertising anchor="adv_tunnels" numbered="true" toc="default">
        <name>Advertising the Tunnels Used for IP Multicast"
               anchor="adv_tunnels"> Multicast</name>
        <t>
          The procedures used for advertising the tunnels that carry IP
          multicast traffic depend upon the type of tunnel being used.  If
          the tunnel type is neither Ingress Replication, Assisted
          Replication, IR, AR,
          nor BIER, there are procedures for advertising both
          "inclusive tunnels" and "selective tunnels".
        </t>
        <t>
          When IR, AR AR, or BIER are used to transmit IP multicast packets
          across the core, there are no P2MP tunnels.  Once an ingress
          EVPN&nbhy;PE
          EVPN-PE determines the set of egress EVPN&nbhy;PEs EVPN-PEs for a
          given flow, the IMET routes contain all the information needed to
          transport packets of that flow to the egress PEs.
        </t>
        <t>
          If AR is used, the ingress EVPN&nbhy;PE EVPN-PE is also an AR&nbhy;LEAF AR-LEAF,
          and the IMET route coming from the selected AR&nbhy;REPLICATOR AR-REPLICATOR
          contains the information needed. The AR&nbhy;REPLICATOR AR-REPLICATOR will
          behave as an ingress EVPN&nbhy;PE EVPN-PE when sending a flow to the
          egress EVPN&nbhy;PEs. EVPN-PEs.
        </t>
        <t>
          If the tunneling technique requires P2MP tunnels to be set up
          (e.g., RSVP&nbhy;TE RSVP-TE P2MP, mLDP, Multipoint LDP (mLDP), or PIM), some of the tunnels may be
          selective tunnels and some may be inclusive tunnels.
        </t>
        <t>
          Selective P2MP tunnels are always advertised by the ingress PE
          using S&nbhy;PMSI A&nbhy;D S-PMSI Auto-Discovery (A-D) routes <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. target="RFC9572" format="default"/>.
        </t>
        <t>
          For inclusive tunnels, there is a choice between using a BD's
          ordinary "BUM tunnel" <xref target="RFC7432"/> target="RFC7432" format="default"/> as the default
          inclusive tunnel for carrying IP multicast traffic, traffic or using a
          separate IP multicast tunnel as the default inclusive tunnel for
          carrying IP multicast. In the former case, the inclusive tunnel is
          advertised in an IMET route.  In the latter case, the inclusive
          tunnel is advertised in a (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D (C-*,C-*) S-PMSI A-D
          route <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. target="RFC9572" format="default"/>.  Details may be found in
          subsequent sections.
        </t>
        <section title="Constructing anchor="sbd-routes" numbered="true" toc="default">
          <name>Constructing Routes for the SBD"
                 anchor="sbd-routes"> SBD</name>
          <t>
            There are situations in which an EVPN&nbhy;PE EVPN-PE needs to originate
            IMET, SMET, and/or SPMSI S-PMSI routes for the SBD.  Throughout this
            document, we will refer to such routes respectively as
            "SBD&nbhy;IMET
            "SBD-IMET routes", "SBD&nbhy;SMET "SBD-SMET routes", and
            "SBD&nbhy;SPMSI
            "SBD-SPMSI routes".  Subsequent sections detail the
            conditions under which these routes need to be originated.
          </t>
          <t>
            When an EVPN&nbhy;PE EVPN-PE needs to originate an SBD&nbhy;IMET,
            SBD&nbhy;SMET, SBD-IMET,
            SBD-SMET, or SBD&nbhy;SPMSI SBD-SPMSI route, it constructs the route
            as follows:
            <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
                the
                The RD field of the route's NLRI is set to the RD of the
                MAC&nbhy;VRF
                MAC-VRF that is associated with the SBD; SBD.
              </t>
            </li>
            <li>
              <t>
                the SBD&nbhy;RT
                The SBD-RT is attached to the route; route.
              </t>
            </li>
            <li>
              <t>
                the "Tag ID"
                The Tag ID field of the route's NLRI is set to the Tag
                ID that has been assigned to the SBD.  This is most likely
                0 if a VLAN&nbhy;based VLAN-based or VLAN&nbhy;bundle VLAN-bundle service is
                being used, used but non-zero if a VLAN-aware bundle service is
                being used.
              </t>
            </list>
          </t>
            </li>
          </ul>
        </section>
        <!-- sbd-routes -->

        <section title="Ingress Replication" anchor="imet-ir"> anchor="imet-ir" numbered="true" toc="default">
          <name>Ingress Replication</name>
          <t>
              When Ingress Replication (IR) is used to transport IP
              multicast frames of a given Tenant Domain, each EVPN&nbhy;PE EVPN-PE
              attached to that Tenant Domain MUST <bcp14>MUST</bcp14> originate an SBD&nbhy;IMET SBD-IMET
              route (see <xref target="sbd-routes"/>). target="sbd-routes" format="default"/>).
          </t>
          <t>
              The SBD&nbhy;IMET SBD-IMET route MUST <bcp14>MUST</bcp14> carry a PMSI Tunnel attribute Attribute
              (PTA), and the MPLS label Label field of the PTA MUST <bcp14>MUST</bcp14> specify a
              downstream-assigned MPLS label that maps uniquely (in the
              context of the originating EVPN&nbhy;PE) EVPN-PE) to the SBD.
          </t>
          <t>
              Following the procedures of <xref target="RFC7432"/>, target="RFC7432" format="default"/>, an
              EVPN&nbhy;PE MUST
              EVPN-PE <bcp14>MUST</bcp14> also originate an IMET route for each BD to
              which it is attached. Each of these IMET routes carries a PTA
              specifying a downstream&nbhy;assigned downstream-assigned label that maps
              uniquely, in the context of the originating EVPN&nbhy;PE, EVPN-PE, to
              the BD in question. These IMET routes need not carry the
              SBD&nbhy;RT.
              SBD-RT.
          </t>
          <t>
              When an ingress EVPN&nbhy;PE EVPN-PE needs to use IR to send an IP
              multicast frame from a particular source BD to an egress
              EVPN&nbhy;PE,
              EVPN-PE, the ingress PE determines whether or not the egress PE
              has originated an IMET route for that BD.  If so, that IMET
              route contains the MPLS label that the egress PE has assigned
              to the source BD.  The ingress PE uses that label when
              transmitting the packet to the egress PE. Otherwise, the
              ingress PE uses the label that the egress PE has assigned to
              the SBD (in the SBD&nbhy;IMET SBD-IMET route originated by the egress).
          </t>
          <t>
              Note that the set of IMET routes originated by a given egress
              PE, and installed by a given ingress PE, may change over time.
              If the egress PE withdraws its IMET route for the source BD,
              the ingress PE MUST <bcp14>MUST</bcp14> stop using the label carried in that IMET
              route,
              route and instead MUST <bcp14>MUST</bcp14> use the label carried in the
              SBD&nbhy;IMET
              SBD-IMET route from that egress PE.  Implementors must
              also take into account that an IMET route from a particular PE
              for a particular BD may arrive after that PE's SBD&nbhy;IMET SBD-IMET
              route.
          </t>
        </section>
        <!-- imet-ir -->
          <section title="Assisted Replication" anchor="imet-ar"> anchor="imet-ar" numbered="true" toc="default">
          <name>Assisted Replication</name>
          <t>
              When Assisted Replication (AR) is used to transport IP multicast
              frames of a given Tenant Domain, each EVPN&nbhy;PE EVPN-PE (including
              the AR&nbhy;REPLICATOR) AR-REPLICATOR) attached to the Tenant Domain MUST <bcp14>MUST</bcp14>
              originate an SBD&nbhy;IMET SBD-IMET route (see <xref
              target="sbd-routes"/>). target="sbd-routes" format="default"/>).
          </t>
          <t>
              An AR&nbhy;REPLICATOR AR-REPLICATOR attached to a given Tenant Domain is
              considered to be an EVPN&nbhy;PE EVPN-PE of that Tenant Domain.  It is
              attached to all the BDs in the Tenant Domain, but it does not
              necessarily have L3 routing instances.
          </t>
          <t>
              As with Ingress Replication, the SBD&nbhy;IMET SBD-IMET route carries a
              PTA where the MPLS label Label field specifies the
              downstream-assigned MPLS label that identifies the
              SBD. However, the AR&nbhy;REPLICATOR AR-REPLICATOR and AR&nbhy;LEAF
              EVPN&nbhy;PEs AR-LEAF
              EVPN-PEs will set the PTA's flags differently, as per
              <xref target="I-D.ietf-bess-evpn-optimized-ir"/>. target="RFC9574" format="default"/>.
          </t>
          <t>
              In addition, each EVPN&nbhy;PE EVPN-PE originates an IMET route for
              each BD to which it is attached.  As in the case of Ingress
              Replication, these routes carry the downstream-assigned MPLS
              labels that identify the BDs and do not carry the SBD&nbhy;RT. SBD-RT.
          </t>
          <t>
              When an ingress EVPN&nbhy;PE, EVPN-PE, acting as AR&nbhy;LEAF, AR-LEAF, needs to
              send an IP multicast frame from a particular source BD to an
              egress EVPN&nbhy;PE, EVPN-PE, the ingress PE determines whether or not there
              is any AR&nbhy;REPLICATOR AR-REPLICATOR that originated an IMET route for
              that BD. After the AR&nbhy;REPLICATOR AR-REPLICATOR selection (if there are
              more than one), the AR&nbhy;LEAF AR-LEAF uses the label contained in
              the IMET route of the AR&nbhy;REPLICATOR AR-REPLICATOR when transmitting
              packets to it. The AR&nbhy;REPLICATOR AR-REPLICATOR receives the packet and,
              based on the procedures specified in <xref target="I-D.ietf-bess-evpn-optimized-ir"/> target="RFC9574" format="default"/>
              and in <xref target="imet-ir"/> target="imet-ir" format="default"/> of this document,
              transmits the packets to the egress EVPN&nbhy;PEs EVPN-PEs using the
              labels contained in the received IMET routes for either the
              source BD or the SBD.
          </t>
          <t>
              If an ingress AR&nbhy;LEAF AR-LEAF for a given BD has not received any
              IMET route for that BD from an AR&nbhy;REPLICATOR, AR-REPLICATOR, the ingress
              AR&nbhy;LEAF
              AR-LEAF follows the procedures in <xref
              target="imet-ir"/>. target="imet-ir" format="default"/>.
          </t>
          <section title = "Automatic anchor="SBD-matching" numbered="true" toc="default">
            <name>Automatic SBD Matching" anchor="SBD-matching"> Matching</name>
            <t>Each PE needs to know a BD's
             corresponding SBD. Configuring that information in each BD
             is one way way, but it requires repetitive configuration and
             consistency checking (to make sure that all the BDs of the same
             tenant are configured with the same SBD). A better way is to
             configure the SBD info in the L3 routing instance so that all
             related BDs will derive the SBD information.
            </t>
            <t>An AR-replicator AR-REPLICATOR also needs to know the same information, though
             it does not necessarily have an L3 routing instance.
             However, from the EVI-RT EC in a BD's IMET route, an AR-replicator AR-REPLICATOR
             can derive the corresponding SBD of that BD without any configuration.
            </t>
          </section>
        </section>
        <!-- imet-ar -->

          <section title="BIER" anchor="imet-bier"> anchor="imet-bier" numbered="true" toc="default">
          <name>BIER</name>
          <t>
              When BIER is used to transport multicast packets of a given
              Tenant Domain, and a given EVPN&nbhy;PE EVPN-PE attached to that
              Tenant Domain is a possible ingress EVPN&nbhy;PE EVPN-PE for traffic
              originating outside that Tenant Domain, the given EVPN&nbhy;PE
              MUST EVPN-PE
              <bcp14>MUST</bcp14> originate an SBD&nbhy;IMET route, SBD-IMET route (see <xref
              target="sbd-routes"/>). target="sbd-routes" format="default"/>).
          </t>
          <t>
              In addition, IMET routes that are originated for other BDs in
              the Tenant Domain MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT. SBD-RT.
          </t>
          <t>
              Each IMET route (including but not limited to the
              SBD&nbhy;IMET
              SBD-IMET route) MUST <bcp14>MUST</bcp14> carry a PMSI Tunnel attribute Attribute (PTA).
              The MPLS label Label field of the PTA MUST <bcp14>MUST</bcp14> specify an
              upstream-assigned MPLS label that maps uniquely (in the
              context of the originating EVPN&nbhy;PE) EVPN-PE) to the BD for which
              the route is originated.
          </t>
          <t>
              Suppose an ingress EVPN&nbhy;PE, EVPN-PE, say PE1, needs to use BIER to
              tunnel an IP multicast frame to a set of egress
              EVPN&nbhy;PEs.
              EVPN-PEs. And suppose the frame's source BD is BD1.  The
              frame is encapsulated as follows:
              <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
                  A four-octet MPLS label stack entry <xref
                  target="RFC3032"/> target="RFC3032" format="default"/> is prepended to the
                  frame.  The Label field is set to the upstream-assigned
                  label that PE1 has assigned to BD1.
              </t>
            </li>
            <li>
              <t>
                  The resulting MPLS packet is then encapsulated in a BIER
                  encapsulation <xref target="RFC8296"/>, target="RFC8296" format="default"/> <xref
                  target="I-D.ietf-bier-evpn"/>. target="I-D.ietf-bier-evpn" format="default"/>.  The BIER BitString is set to
                  identify the egress EVPN&nbhy;PEs. EVPN-PEs.  The BIER "proto" Proto field
                  is set to the value for "MPLS packet with
                  upstream&nbhy;assigned an
                  upstream-assigned label at top of the stack".
              </t>
              </list>
            </t>
            </li>
          </ul>
          <t>
              Note: It is possible that the packet being tunneled from PE1
              originated outside the Tenant Domain.  In this case, the
              actual source BD (BD1) BD, BD1, is considered to be the SBD, and the
              upstream&nbhy;assigned
              upstream-assigned label it carries will be the label that
              PE1 assigned to the SBD, SBD and advertised in its SBD&nbhy;IMET SBD-IMET
              route.
          </t>
          <t>
              Suppose an egress PE, say PE2, receives such a BIER packet. The
              BFIR&nbhy;id
              BFIR-id field of the BIER header allows PE2 to determine
              that the ingress PE is PE1. There are then two cases to
              consider:
              <list style="numbers">
          </t>
          <ol spacing="normal" type="1"><li>
              <t>
                  PE2 has received and installed an IMET route for BD1 from
                  PE1.
                  <vspace/>
                  <vspace/>
              </t>
              <t>
                  In this case, the BIER packet will be carrying the
                  upstream&nbhy;assigned
                  upstream-assigned label that is specified in the PTA
                  of that IMET route.  This enables PE2 to determine the
                  "apparent source BD" (as defined in <xref
                  target="egress_irb_use"/>). target="egress_irb_use" format="default"/>).
                  <!-- that -->
                  <!-- BD1 is the source BD of the IP multicast frame carried by -->
                  <!-- the BIER packet. -->
              </t>
            </li>
            <li>
              <t>
                  PE2 has not received and installed an IMET route for BD1
                  from PE1.
                  <vspace/>
                  <vspace/>
              </t>
              <t>
                  In this case, PE2 will not recognize the
                  upstream&nbhy;assigned
                  upstream-assigned label carried in the BIER
                  packet. PE2 MUST <bcp14>MUST</bcp14> discard the packet.
              </t>
              </list>
            </t>
            </li>
          </ol>
          <t>
              Further details on the use of BIER to support EVPN can be
              found in <xref target="I-D.ietf-bier-evpn"/>. target="I-D.ietf-bier-evpn" format="default"/>.
          </t>
        </section>
        <!-- imet-bier -->

        <section title="Inclusive anchor="adv_incl" numbered="true" toc="default">
          <name>Inclusive P2MP Tunnels" anchor="adv_incl"> Tunnels</name>
          <section title="Using anchor="ip_bum" numbered="true" toc="default">
            <name>Using the BUM Tunnels as IP Multicast Inclusive
                          Tunnels"
                   anchor="ip_bum"> Tunnels</name>
            <t>
              The procedures in this section apply only when
              <list style="format (%c)"> when:
            </t>
            <ol spacing="normal" type="%c)"><li>
                <t>
                  it is desired to use the BUM tunnels to carry IP multicast
                  traffic across the backbone, backbone and
                </t>
              </li>
              <li>
                <t>
                  the BUM tunnels are P2MP tunnels (i.e., neither IR, AR,
                  nor BIER are being used to transport the BUM traffic).
                </t>
              </list>
            </t>
              </li>
            </ol>
            <t>
              In this case, an IP multicast frame (whether inter&nbhy;subnet inter-subnet
              or intra&nbhy;subnet) intra-subnet) will be carried across the backbone in
              the BUM tunnel belonging to its source BD.  Each EVPN&nbhy;PE EVPN-PE
              attached to a given Tenant Domain needs to join the BUM
              tunnels for every BD in the Tenant Domain, even those BDs to
              which the EVPN&nbhy;PE EVPN-PE is not locally attached.  This ensures
              that an IP multicast packet from any source BD can reach all
              PEs attached to the Tenant Domain.
            </t>
            <t>
              Note that this will cause all the BUM traffic from a given BD
              in a Tenant Domain to be sent to all PEs that attach to that
              Tenant Domain, even the PEs that don't attach to the given BD.
              To avoid this, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the BUM tunnels not be
              used as IP Multicast inclusive tunnels, tunnels and that the
              procedures of <xref target="wc_spmsi"/> target="wc_spmsi" format="default"/> be used instead.
            </t>
            <t>
              If a PE is a possible ingress EVPN&nbhy;PE EVPN-PE for traffic
              originating outside the Tenant Domain, the PE MUST <bcp14>MUST</bcp14> originate
              an SBD&nbhy;IMET SBD-IMET route (see <xref target="sbd-routes"/>). target="sbd-routes" format="default"/>).
              This route MUST <bcp14>MUST</bcp14> carry a PTA specifying the P2MP tunnel used
              for transmitting IP multicast packets that originate outside
              the tenant domain.  All EVPN&nbhy;PEs EVPN-PEs of the Tenant Domain
              MUST
              <bcp14>MUST</bcp14> join the tunnel specified in the PTA of an SBD&nbhy;IMET SBD-IMET
              route:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>
                  If the tunnel is an RSVP-TE P2MP tunnel, the originator of
                  the route MUST <bcp14>MUST</bcp14> use RSVP-TE P2MP procedures to add each PE
                  of the Tenant Domain to the tunnel, even PEs that have not
                  originated an SBD&nbhy;IMET SBD-IMET route.
                </t>
              </li>
              <li>
                <t>
                  If the tunnel is an mLDP or PIM tunnel, each PE importing
                  the SBD&nbhy;IMET SBD-IMET route MUST <bcp14>MUST</bcp14> add itself to the tunnel,
                  using mLDP or PIM procedures, respectively.
                </t>
              </list>
            </t>
              </li>
            </ul>
            <t>
              Whether or not a PE originates an SBD&nbhy;IMET SBD-IMET route, it will
              of course originate an IMET route for each BD to which it is
              attached. Each of these IMET routes MUST <bcp14>MUST</bcp14> carry the
              SBD&nbhy;RT,
              SBD-RT, as well as the RT for the BD to which it belongs.
            </t>
            <t>
              If a received IMET route is not the SBD&nbhy;IMET SBD-IMET route, it
              will also be carrying the RT for its source BD.  The route's
              NLRI will carry the Tag ID for the source BD.  From the RT and
              the Tag ID, any PE receiving the route can determine the
              route's source BD.
            </t>
            <t>
              If the MPLS label Label field of the PTA contains zero, the
              specified P2MP tunnel is used only to carry frames of a single
              source BD.
            </t>
            <t>
              If the MPLS label Label field of the PTA does not contain zero, it
              MUST
              <bcp14>MUST</bcp14> contain an upstream-assigned MPLS label that maps
              uniquely (in the context of the originating EVPN&nbhy;PE) EVPN-PE) to
              the source BD (or, (or in the case of an SBD&nbhy;IMET SBD-IMET route, to
              the SBD).  The tunnel may then be used to carry frames of
              multiple source BDs.  The apparent source BD of a particular
              packet is inferred from the label carried by the packet.
            </t>
            <t>
             IP multicast traffic originating outside the Tenant Domain is
             transmitted with the label corresponding to the SBD, as
             specified in the ingress EVPN&nbhy;PE's SBD&nbhy;IMET EVPN-PE's SBD-IMET route.
            </t>
          </section>
          <!-- ip_bum -->
        <section title="Using anchor="wc_spmsi" numbered="true" toc="default">
            <name>Using Wildcard S&nbhy;PMSI S-PMSI A-D Routes to Advertise                         Inclusive Tunnels Specific to IP Multicast"
                 anchor="wc_spmsi"> Multicast</name>
            <t>
            The procedures of this section apply when (and only when) it is
            desired to transmit IP multicast traffic on an inclusive tunnel, tunnel
            but not on the same tunnel used to transmit BUM traffic.
            </t>
            <t>
             However, these procedures do NOT apply when the tunnel type is
             Ingress Replication or BIER, EXCEPT in the case where it is
             necessary to interwork between non&nbhy;OISM non-OISM PEs and OISM PEs,
             as specified in <xref target="no-OISM"/>. target="no-OISM" format="default"/>.
            </t>
            <t>
             Each EVPN&nbhy;PE EVPN-PE attached to the given Tenant Domain MUST <bcp14>MUST</bcp14>
             originate an SBD&nbhy;SPMSI A&nbhy;D SBD-SPMSI A-D route.  The NLRI of that
             route MUST <bcp14>MUST</bcp14> contain (C&nbhy;*,C&nbhy;*) (C-*,C-*) (see <xref
             target="RFC6625"/>). target="RFC6625" format="default"/>). Additional rules for constructing that
             route are given in <xref target="sbd-routes"/>. target="sbd-routes" format="default"/>.
            </t>
            <t>
             In addition, an EVPN&nbhy;PE MUST EVPN-PE <bcp14>MUST</bcp14> originate an S&nbhy;PMSI
             A&nbhy;D S-PMSI
             A-D route containing (C&nbhy;*,C&nbhy;*) (C-*,C-*) in its NLRI for
             each of the other BDs, in the given Tenant Domain, to which it
             is attached.  All such routes MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT. SBD-RT.  This
             ensures that those routes are imported by all EVPN&nbhy;PEs EVPN-PEs
             attached to the Tenant Domain.
            </t>
            <t>
             A PE receiving these routes follows the procedures of <xref
             target="bd_route"/> target="bd_route" format="default"/> to determine which BD the route is for.
             <!-- The route carrying the PTA will also be carrying the RT for -->
             <!-- that source BD, and the route's NLRI will contain the Tag ID -->
             <!-- for that source BD.  This allows any PE receiving the route to -->
             <!-- determine the source BD associated with the route. -->
            </t>
            <t>
              If the MPLS label Label field of the PTA contains zero, the
              specified tunnel is used only to carry frames of a single
              source BD.
            </t>
            <t>
              If the MPLS label Label field of the PTA does not contain zero, it
              MUST
              <bcp14>MUST</bcp14> specify an upstream-assigned MPLS label that maps
              uniquely (in the context of the originating EVPN&nbhy;PE) EVPN-PE) to
              the source BD.  The tunnel may be used to carry frames of
              multiple source BDs, and the apparent source BD for a
              particular packet is inferred from the label carried by the
              packet.
            </t>
            <t>
              The EVPN&nbhy;PE EVPN-PE advertising these S&nbhy;PMSI A&nbhy;D route S-PMSI A-D
              routes is specifying the default tunnel that it will use (as
              ingress PE) for transmitting IP multicast packets.  The
              upstream-assigned label allows an egress PE to determine the
              apparent source BD of a given packet.
            </t>
          </section>
          <!-- wc-spmsi -->

          <!-- <section title="RSVP-TE P2MP" anchor="wc-rsvp"> -->
          <!--   <t> -->
          <!--     When RSVP-TE P2MP is used to transport multicast packets of a -->
          <!--     given Tenant Domain on an inclusive tunnel, and it is desired -->
          <!-- to avoid using the BUM tunnels, then each EVPN&nbhy;PE
               attached to -->
          <!-- that Tenant Domain MUST <bcp14>MUST</bcp14> originate an SBD&nbhy;SPMSI A-D
               route.  The -->
          <!-- NLRI of that route MUST <bcp14>MUST</bcp14> contain (C&nbhy;*,C&nbhy;*) (see
               <xref -->
          <!--     target="RFC625"/>). Additional rules for constructing that -->
          <!--     route are given in <xref target="sbd-spmsi"/>. -->
          <!--   </t> -->
          <!--   <t> -->
          <!-- In addition, an EVPN&nbhy;PE MUST <bcp14>MUST</bcp14> originate an S&nbhy;PMSI A-D
               route -->
          <!-- containing (C&nbhy;*,C&nbhy;*) in its NLRI for each of the
               other BDs in -->
          <!--     the Tenant Domain to which it is attached.  All such route -->
          <!-- MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT.  This ensures that those routes
               are -->
          <!-- imported by all EVPN&nbhy;PEs attached to the Tenant
               Domain. -->
          <!--   </t> -->
          <!--   <t> -->
          <!--     Each S&nbhy;PMSI A-D route (including but not limited to the -->
          <!-- SBD&nbhy;SPMSI route) MUST <bcp14>MUST</bcp14> carry a PMSI Tunnel attribute
               (PTA). -->
          <!--     The MPLS label field of the PTA MUST <bcp14>MUST</bcp14> specify an -->
          <!--     upstream-assigned MPLS label that maps uniquely (in the -->
          <!-- context of the originating EVPN&nbhy;PE) to the SBD. -->
          <!--   </t> -->
          <!--   <t> -->
          <!-- The EVPN&nbhy;PE advertising these S&nbhy;PMSI A-D route routes is
               -->
          <!--     specifying the default tunnel that it will use (as ingress PE) -->
          <!--     for transmitting IP multicast packets.  The upstream-assigned -->
          <!--     label allows an egress PE to determine the source BD of a -->
          <!--     given packet. -->
          <!--   </t> -->

          <!-- </section> <!-\- wc-rsvp -\-> -->

          <!-- <section title="mLDP or PIM" anchor="wc-recv"> -->
          <!--   <t> -->
          <!--     When either mLDP or PIM (or any other protocol that uses a -->
          <!--     receiver-driven technique to build P2MP or MP2MP trees) is -->
          <!--     used to transport multicast packets of a given Tenant Domain -->
          <!--     on an inclusive tunnel, and it is desired to avoid using the -->
          <!--     BUM tunnels, the procedures of this section apply. -->
          <!--   </t> -->
          <!--   <t> -->
          <!--     then each, -->
          <!-- an EVPN&nbhy;PE attached to that Tenant Domain MUST NOT <bcp14>MUST NOT</bcp14>
               originate -->
          <!-- an SBD&nbhy;IMET route. -->
          <!--   </t> -->
          <!--   <t> -->
          <!--     However, IMET routes that are originated for other BDs in the -->
          <!-- Tenant Domain MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT. -->
          <!--   </t> -->
          <!--   <t> -->
          <!--     Each IMET route MUST <bcp14>MUST</bcp14> carry a PMSI Tunnel attribute (PTA), and -->
          <!--     the MPLS label field of the PTA MUST <bcp14>MUST</bcp14> specify an -->
          <!--     upstream-assigned MPLS label that maps uniquely (in the -->
          <!-- context of the originating EVPN&nbhy;PE) to a particular
               BD. -->
          <!--   </t> -->
          <!--   <t> -->
          <!-- The EVPN&nbhy;PE advertising these IMET routes is specifying
               the -->
          <!--     default tunnel that it will use (as ingress PE) for -->
          <!--     transmitting IP multicast packets.  The upstream-assigned -->
          <!--     label allows an egress PE to determine the source BD of a -->
          <!--     given packet. -->
          <!--   </t> -->
          <!--   <t> -->
          <!--     The procedures of this section <xref target="imet-recv"/> -->
          <!--     apply whenever the tunnel technology is based on the -->
          <!--     construction of the multicast trees in a "receiver-driven" -->
          <!--     manner; mLDP and PIM are two ways of constructing trees in a -->
          <!--     receiver-driven manner. -->
          <!--   </t> -->
          <!-- </section> <!-\- wc-recv -\-> -->

        </section>
        <!-- wc_spmsi-->

      <section title="Selective Tunnels" anchor="adv_secl"> anchor="adv_secl" numbered="true" toc="default">
          <name>Selective Tunnels</name>
          <t>
          An ingress EVPN&nbhy;PE EVPN-PE for a given multicast flow or set of flows
          can always assign the flow to a particular P2MP tunnel by
          originating an S&nbhy;PMSI A&nbhy;D S-PMSI A-D route whose NLRI identifies
          the flow or set of flows.  The NLRI of the route could be
          (C&nbhy;*,C&nbhy;G),
          (C-*,C-G) or (C&nbhy;S,C&nbhy;G). (C-S,C-G).  The S&nbhy;PMSI
          A&nbhy;D S-PMSI
          A-D route MUST <bcp14>MUST</bcp14> carry the SBD&nbhy;RT, SBD-RT so that it is imported
          by all EVPN&nbhy;PEs EVPN-PEs attached to the Tenant Domain.
          </t>
          <!-- <t> -->
        <!--   <cref source=" ECR"> -->
        <!-- Any need for (C&nbhy;S,C&nbhy;*)? -->
        <!--   </cref> -->
        <!-- </t> -->
        <t>
          An S&nbhy;PMSI A&nbhy;D S-PMSI A-D route is "for" a particular source BD.  It
          MUST
          <bcp14>MUST</bcp14> carry the RT associated with that BD, and it MUST <bcp14>MUST</bcp14> have the
          Tag ID for that BD in its NLRI.
          </t>
          <t>
          When an EVPN&nbhy;PE EVPN-PE imports an S&nbhy;PMSI A&nbhy;D S-PMSI A-D route, it
          applies the rules of <xref target="bd_route"/> target="bd_route" format="default"/> to associate the
          route with a particular BD.
          </t>
          <t>
          Each such route MUST <bcp14>MUST</bcp14> contain a PTA, as specified in <xref
          target="wc_spmsi"/>. target="wc_spmsi" format="default"/>.
          </t>
          <t>
          An egress EVPN&nbhy;PE EVPN-PE interested in the specified flow or flows
          MUST
          <bcp14>MUST</bcp14> join the specified tunnel.  Procedures for joining the
          specified tunnel are specific to the tunnel type.  (Note that if
          the tunnel type is RSVP&nbhy;TE RSVP-TE P2MP LSP, the Leaf Information
          Required (LIR) flag of the PTA SHOULD NOT <bcp14>SHOULD NOT</bcp14> be set.  An ingress OISM
          PE knows which OISM EVPN PEs are interested in any given flow, flow and
          hence can add them to the RSVP&nbhy;TE RSVP-TE P2MP tunnel that carries
          such flows.)
          <!-- If the tunnel is an -->
          <!-- RSVP-TE P2MP LSP, joining the tunnel will require the sending of -->
          <!-- Leaf A-D routes, as discussed in <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. -->
          </t>
          <t>
          If the PTA does not specify a non-zero MPLS label, the apparent
          source BD of any packets that arrive on that tunnel is considered
          to be the BD associated with the route that carries the PTA.  If
          the PTA does specify a non-zero MPLS label, the apparent source BD
          of any packets that arrive on that tunnel carrying the specified
          label is considered to be the BD associated with the route that
          carries the PTA.
          </t>
          <t>
          It should be noted that that, when either IR or BIER is used, there is
          no need for an ingress PE to use S&nbhy;PMSI A&nbhy;D S-PMSI A-D routes to
          assign specific flows to selective tunnels.  The procedures of
          <xref target="smet_adv"/>, target="smet_adv" format="default"/>, along with the procedures of Sections <xref
          target="imet-ir"/>, target="imet-ir" format="counter"/>, <xref target="imet-ar"/>, or target="imet-ar" format="counter"/>, and <xref
          target="imet-bier"/>, target="imet-bier" format="counter"/>, provide the functionality of selective
          tunnels without the need to use S&nbhy;PMSI A&nbhy;D S-PMSI A-D routes.
          </t>
        </section>
        <!-- adv_secl -->
    </section>
      <!-- adv_incl -->

    <section title="Advertising anchor="smet_adv" numbered="true" toc="default">
        <name>Advertising SMET Routes" anchor="smet_adv"> Routes</name>
        <t>
        <xref target="RFC9251"/> target="RFC9251" format="default"/> allows an egress EVPN&nbhy;PE EVPN-PE to express
        its interest in a particular multicast flow or set of flows by
        originating an a SMET route.  The NLRI of the SMET route identifies
        the flow or set of flows as (C&nbhy;*,C&nbhy;*) or
        (C&nbhy;*,C&nbhy;G) (C-*,C-*),
        (C-*,C-G), or (C&nbhy;S,C&nbhy;G). (C-S,C-G).
        </t>
        <t>
        Each SMET route belongs to a particular BD.  The Tag ID for the BD
        appears in the NLRI of the route, and the route carries the RT
        associated with that BD.  From this &lt;RT,&nbsp;tag&gt; &lt;RT, tag&gt; pair, other
        EVPN&nbhy;PEs
        EVPN-PEs can identify the BD to which a received SMET route
        belongs. (Remember though that the route may be carrying multiple
        RTs.)
        </t>
        <t>
        There are three cases to consider:
        <list style="symbols">
        </t>
        <ol spacing="normal" type="Case %d:">
          <li>
            <t>
            Case 1:
            It is known that no BD of a Tenant Domain contains a
            multicast router.
            <vspace/>
            <vspace/>
            </t>
            <t>
            In this case, an egress PE advertises its interest in a flow or
            set of flows by originating an a SMET route that belongs to the
            SBD.  We refer to this as an SBD&nbhy;SMET SBD-SMET route.  The
            SBD&nbhy;SMET
            SBD-SMET route carries the SBD&nbhy;RT, SBD-RT and has the Tag ID
            for the SBD in its NLRI. SMET routes for the individual BDs are
            not needed, because there is no need for a PE that receives an a
            SMET route to send a corresponding IGMP/MLD Join message on any of
            its ACs.
            </t>
          </li>
          <li>
            <t>
            Case 2:
            It is known that more than one BD of a Tenant Domain may
            contain a multicast router.
            <vspace/>
            <vspace/>
            </t>
            <t>
            This is very much like Case 1.  An egress PE advertises its interest
            in a flow or set of flows by originating an SBD&nbhy;SMET SBD-SMET route.
            The SBD&nbhy;SMET SBD-SMET route carries the SBD&nbhy;RT, SBD-RT and has the Tag
            ID for the SBD in its NLRI.
            <vspace/>
            <vspace/>
            </t>
            <t>
            In this case, it is important to be sure that SMET routes for
            the individual BDs are not originated.  Suppose, for  For example, suppose
            that PE1 had local receivers for a given flow on both BD1 and
            BD2,
            BD2 and that it originated SMET routes for both those BDs.
            Then
            Then, PEs receiving those SMET routes might send IGMP/MLD Joins on
            both those BDs.  This could cause externally sourced multicast
            traffic to enter the Tenant Domain at both BDs, which could
            result in duplication of data.
            <vspace/>
            <vspace/>
            </t>
            <t>
            Note that if it is possible that more than one BD contains a tenant
            multicast router, then in order to receive multicast data
            originating from outside EVPN, the PEs MUST <bcp14>MUST</bcp14> follow the
            procedures of <xref target="external"/>. target="external" format="default"/>.
            </t>
          </li>
          <li>
            <t>
            Case 3:
            It is known that only a single BD of a Tenant Domain
            contains a multicast router.
            <vspace/>
            <vspace/>
            </t>
            <t>
            Suppose that an egress PE is attached to a BD on which there
            might be a tenant multicast router.  (The tenant router is not
            necessarily on a segment that is attached to that PE.)  And
            suppose that the PE has one or more ACs attached to that BD BD,
            which are interested in a given multicast flow.  In this case,
            in addition to the SMET route for the SBD, the egress PE MAY <bcp14>MAY</bcp14>
            originate an a SMET route for that BD.  This will enable the
            ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as
            specified in <xref target="RFC9251"/>. target="RFC9251" format="default"/>.  As long as that is
            the only BD on which there is a tenant multicast router, there
            is no possibility of duplication of data.
            <!-- <vspace/> -->
            <!-- <vspace/> -->
            <!-- If an SMET route is not an SBD&nbhy;SMET route, and if the SMET -->
            <!-- route is for (C&nbhy;S,C&nbhy;G) (i.e., no wildcard source), and -->
            <!-- if the EVPN&nbhy;PE originating it knows the source BD of -->
            <!-- C&nbhy;S, it MAY put only the RT for that BD on the route. -->
            <!-- Otherwise, the route MUST carry the SBD&nbhy;RT, so that it gets -->
            <!-- distributed to all the EVPN&nbhy;PEs attached to the tenant -->
            <!-- domain. -->
            <!-- <vspace/> -->
            <!-- <vspace/> -->
            </t>
        </list>
      </t>
          </li>
        </ol>
        <t>
        This document does not specify procedures for dynamically
        determining which of the three cases applies to a given deployment;
        the PEs of a given Tenant Domain MUST <bcp14>MUST</bcp14> be provisioned to know which
        case applies.
        </t>
        <t>
		As detailed in [RFC9251], an <xref target="RFC9251"/>, a SMET route carries flags indicating whether IGMP (v1, v2 v2, or v3) or MLD (v1 or v2) messages should be triggered on the ACs of the BD to which the SMET route belongs. For IGMP v3 and MLD v2, the IE Include/Exclude (IE) flag also indicates whether the source information in the SMET route is of an Include Group type or Exclude Group type. If an SBD PE needs to generate IGMP/MLD reports as (as it is the case in section 6.2), <xref target="external_pim_router"/>) or the route is for an (S, G) state, the value of the flags MUST <bcp14>MUST</bcp14> be set according to the rules in [RFC9251]. <xref target="RFC9251"/>. Otherwise, the flags SHOULD <bcp14>SHOULD</bcp14> be set to 0.
        </t>

<!--[rfced] We are having difficulty parsing this sentence. Please review
and let us know how it may be updated for clarity.

Original:
   Note that a PE only needs to originate the set of SBD-SMET routes
   that are needed to receive multicast traffic in which it is
   interested.

Perhaps:
   Note that a PE only needs to originate the set of SBD-SMET routes
   that are needed in order to receive multicast traffic that the PE is
   interested in.
-->

        <t>
        Note that a PE only needs to originate the set of SBD&nbhy;SMET SBD-SMET
        routes that are needed to receive multicast traffic in which it is
        interested.  Suppose PE1 has ACs attached to BD1 that are interested
        in (C&nbhy;*,C&nbhy;G) traffic, (C-*,C-G) traffic and ACs attached to BD2 that are
        interested in (C&nbhy;S,C&nbhy;G) (C-S,C-G) traffic.  A single SBD&nbhy;SMET SBD-SMET
        route specifying (C&nbhy;*,C&nbhy;G) (C-*,C-G) will attract all the necessary
        flows.
        </t>
        <t>
        As another example, suppose the ACs attached to BD1 are interested
        in (C&nbhy;*,C&nbhy;G) (C-*,C-G) but not in (C&nbhy;S,C&nbhy;G), (C-S,C-G), while the ACs
        attached to BD2 are interested in (C&nbhy;S,C&nbhy;G). (C-S,C-G).  A single
        SBD&nbhy;SMET
        SBD-SMET route specifying (C&nbhy;*,C&nbhy;G) (C-*,C-G) will pull in all
        the necessary flows.
        </t>
        <t>
        In other words, to determine the set of SBD&nbhy;SMET SBD-SMET routes that
        have to be sent for a given C&nbhy;G, C-G, the PE has to merge the
        IGMP/MLD state for all the BDs (of the given Tenant Domain) to which
        it is attached.
        </t>
        <t>
        Per <xref target="RFC9251"/>, target="RFC9251" format="default"/>, importing an a SMET route for a
        particular BD will cause the IGMP/MLD state to be instantiated for the
        IRB interface to that BD.  This also applies as well when the BD is the
        SBD.
        </t>
        <t>
        However, traffic that originates in one of the actual BDs of a
        particular Tenant Domain MUST NOT <bcp14>MUST NOT</bcp14> be sent down the IRB interface
        that connects the L3 routing instance of that Tenant Domain to the
        SBD.  That would cause duplicate delivery of traffic, since such
        traffic will have already been distributed throughout the Tenant
        Domain.  Therefore, when setting up the IGMP/MLD state based on
        SBD&nbhy;SMET
        SBD-SMET routes, care must be taken to ensure that the IRB
        interface to the SBD is not added to the Outgoing Interface (OIF)
        list if the traffic originates within the Tenant Domain.
        </t>
        <t>
        There are some multicast scenarios that make use of "anycast
        sources".  For example, two different sources may share the same
        anycast IP address, say S1, and each may transmit an (S1,G)
        multicast flow.  In such a scenario, the two (S1,G) flows are
        typically identical.  Ordinary PIM procedures will cause only one of
        the flows to be delivered to each receiver that has expressed
        interest in either (*,G) or (S1,G).  However, the OISM procedures
        described in this document will result in both of the (S1,G) flows
        being distributed in the Tenant Domain, and duplicate delivery will
        result.  Therefore, if there are receivers for (*,G) in a given
        Tenant Domain, there MUST NOT <bcp14>MUST NOT</bcp14> be anycast sources for G within that
        Tenant Domain.  (This restriction could be lifted by defining
        additional procedures; however however, that is outside the scope of this
        document.)
        </t>
      </section>
      <!-- smet_adv -->
  </section>
    <!-- adv_tunnels -->

  <section title="Constructing anchor="mcast_state" numbered="true" toc="default">
      <name>Constructing Multicast Forwarding State"
           anchor="mcast_state"> State</name>
      <section title="Layer anchor="l2_state" numbered="true" toc="default">
        <name>Layer 2 Multicast State" anchor="l2_state"> State</name>
        <t>
          An EVPN&nbhy;PE EVPN-PE maintains "layer 2 multicast state" for each BD to
          which it is attached. Note that this is used for forwarding IP
		  multicast frames based on the inner IP header. The state is
		  learned through IGMP/MLD snooping <xref target="RFC4541"/> target="RFC4541" format="default"/>
		  and procedures in this document.
        </t>
        <t>
          Let PE1 be an EVPN&nbhy;PE, EVPN-PE and BD1 be a BD to which it is
          attached.  At PE1, BD1's layer 2 multicast state for a given
          (C&nbhy;S,C&nbhy;G)
          (C-S,C-G) or (C&nbhy;*,C&nbhy;G) (C-*,C-G) governs the disposition
          of an IP multicast packet that is received by BD1's layer 2
          multicast function on an EVPN&nbhy;PE. EVPN-PE.
        </t>
        <t>
           An IP multicast (S,G) packet is considered to have been received
           by BD1's layer 2 multicast function in PE1 in the following
           cases:
            <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
                The packet is the payload of an Ethernet frame received by PE1
                from an AC that attaches to BD1.
            </t>
          </li>
          <li>
            <t>
                The packet is the payload of an Ethernet frame whose
                apparent source BD is BD1, and which is received by the PE1
                over a tunnel from another EVPN&nbhy;PE. EVPN-PE.
            </t>
          </li>
          <li>
            <t>
                The packet is received from BD1's IRB interface (i.e., has
                been transmitted by PE1's L3 routing instance down BD1's IRB
                interface).
            </t>
            </list>
          </t>
          </li>
        </ul>
        <t>
          According to the procedures of this document, all transmission transmissions of
          IP multicast packets from one EVPN&nbhy;PE EVPN-PE to another is are done at
          layer 2.  That is, the packets are transmitted as Ethernet frames,
          according to the layer 2 multicast state.
        </t>
        <t>
          Each layer 2 multicast state (S,G) or (*,G) contains a set of "output
          interfaces" (OIF list).  The disposition of an (S,G) multicast
          frame received by BD1's layer 2 multicast function is determined
          as follows:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
              The OIF list is taken from BD1's layer 2 (S,G) state, or if
              there is no such (S,G) state, then it is taken from BD1's (*,G) state.
              (If neither state exists, the OIF list is considered to be
              null.)
            </t>
          </li>
          <li>
            <t>
              The rules of <xref target="iif_oif"/> target="iif_oif" format="default"/> are applied to the OIF
              list.  This will generally result in the frame being
              transmitted to some, but not all, elements of the OIF list.
            </t>
          </list>
        </t>
          </li>
        </ul>
        <t>
          Note that there is no Reverse Path Forwarding (RPF) check at layer 2.
          <!-- In EVPN multicast, it -->
          <!-- is assumed that a given IP source address appears on only a single -->
          <!-- segment at any one time, therefore no RPF check is -->
          <!-- necessary. However, the OIF list used by a particular PE for a -->
          <!-- particular (S,G) frame depends on the way that the frame was -->
          <!-- received. -->
        </t>
        <section title="Constructing anchor="oif_construct" numbered="true" toc="default">
          <name>Constructing the OIF List"
                 anchor="oif_construct"> List</name>
          <t>
            In this document, we have extended the procedures of <xref
            target="RFC9251"/> target="RFC9251" format="default"/> so that IMET and SMET routes for a
            particular BD are distributed not just to PEs that attach to
            that BD, BD but to PEs that attach to any BD in the Tenant Domain.
            In this way, each PE attached to a given Tenant Domain learns,
            from other another PE attached to the same Tenant Domain, the set
            of flows that are of interest to each of those other PEs.  (If
            some PE attached to the Tenant Domain does not support <xref
            target="RFC9251"/>, target="RFC9251" format="default"/>, it will be assumed to be interested in
            all flows.  Whether or not a particular remote PE supports <xref
            target="RFC9251"/> target="RFC9251" format="default"/> is determined by the presence of an
            Extended Community in its IMET route; this is specified in <xref
            target="RFC9251"/>.) target="RFC9251" format="default"/>.)  If a set of remote PEs are interested
            in a particular flow, the tunnels used to reach those PEs are
            added to the OIF list of the multicast states corresponding to
            that flow.
          </t>
          <t>
            An EVPN&nbhy;PE EVPN-PE may run IGMP/MLD snooping procedures
			<xref target="RFC4541"/> target="RFC4541" format="default"/> on each of its ACs, ACs
            in order to determine the set of flows of interest to each AC.
            (An AC is said to be interested in a given flow if it connects
            to a segment that has tenant systems interested in that flow.)
            If IGMP/MLD procedures are not being run on a given AC, that AC
            is considered to be interested in all flows.  For each BD, the
            set of ACs interested in a given flow is determined, and the ACs
            of that set are added to the OIF list of that BD's multicast
            state for that flow.
          </t>
          <t>
            The OIF list for each multicast state must also contain the
            IRB interface for the BD to which the state belongs.
            <!-- However, a given frame will be sent up only one -->
            <!-- IRB interface, depending upon the source BD of the frame.  This -->
            <!-- is explained further in <xref target="iif_oif"/>.             -->
          </t>
          <t>
            Implementors should note that the OIF list of a multicast state
            will change from time to time as ACs and/or remote PEs either
            become interested in, in or lose interest in, in particular multicast
            flows.
          </t>
        </section>
        <!-- oif_construct -->

        <section title="Data anchor="iif_oif" numbered="true" toc="default">
          <name>Data Plane: Applying the OIF List to an (S,G) Frame"
                 anchor="iif_oif"> Frame</name>
          <t>
            When an (S,G) multicast frame is received by the layer 2
            multicast function of a given EVPN&nbhy;PE, EVPN-PE, say PE1, its
            disposition depends upon (a) on the way it was received, (b) upon the
            OIF list of the corresponding multicast state (see <xref
            target="oif_construct"/>), target="oif_construct" format="default"/>), (c) upon the "eligibility" of an AC
            to receive a given frame (see <xref target="ac_eligibility"/>) target="ac_eligibility" format="default"/>),
            and (d) upon its apparent source BD (see <xref
            target="adv_tunnels"/> target="adv_tunnels" format="default"/> for information about determining the
            apparent source BD of a frame received over a tunnel from
            another PE).
          </t>
          <section title="Eligibility anchor="ac_eligibility" numbered="true" toc="default">
            <name>Eligibility of an AC to Receive a Frame"
                  anchor="ac_eligibility"> Frame</name>
            <t>
           A given (S,G) multicast frame is eligible to be transmitted by a
           given PE, say PE1, on a given AC, say AC1, only if one of the
           following conditions holds:
            <list style="format %d.">
            </t>
            <ol spacing="normal" type="1"><li>
                <t>
                ESI
                Ethernet Segment Identifier (ESI) labels are being used, PE1 is the DF for the segment to
                which AC1 is connected, and the frame did not originate from
                that same segment (as determined by the ESI label), or label).
                </t>
              </li>
              <li>
                <t>
                The ingress PE for the frame is a remote PE, say PE2,
                local bias is being used, and PE2 is not connected to
                the same segment as AC1.
                </t>
              </li>
              <!-- <t> -->
              <!--   <cref source=" ECR"> -->
              <!-- Of course, if the frame has no ingress EVPN&nbhy;PE -->
              <!--     (maybe it comes from MVPN) or if we can't tell who -->
              <!-- the ingress EVPN&nbhy;PE is, this won't work.  -->
              <!--   </cref> -->
              <!-- </t> -->
            </list>
         </t>
            </ol>
          </section>
          <!-- ac_eligibility -->

       <section title="Applying anchor="oif_apply" numbered="true" toc="default">
            <name>Applying the OIF List" anchor="oif_apply"> List</name>
            <t>
           Assume a given (S,G) multicast frame has been received by a given
           PE, say PE1.  PE1 determines the apparent source BD of the frame,
           finds the layer 2 (S,G) state for that BD (or the (*,G)
           state if there is no (S,G) state), and uses the OIF list from
           that state.  (Note that if PE1 is not attached to the actual
           source BD, the apparent source BD will be the SBD.)
            </t>
         <t>

<!--[rfced] We rephrased this sentence slightly for better
readability. Please let us know of any concerns.

Original:
   Suppose PE1 has determined the frame's apparent source BD to be BD1
   (which may or may not be the SBD.)  There are the following cases to
   consider:
           <list style="format %d.">

Current:
   If PE1 has determined the frame's apparent source BD to be BD1
   (which may or may not be the SBD), then the following cases
   should be considered:
-->

            <t>
           If PE1 has determined the frame's apparent source BD to be
           BD1 (which may or may not be the SBD), then the following
           cases should be considered:
            </t>
            <ol spacing="normal" type="1"><li>
                <t>
               The frame was received by PE1 from a local AC, say AC1, that
               attaches to BD1.
               <list style="format %c.">
                </t>
                <ol spacing="normal" type="a"><li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent on all local ACs of BD1 that
                   appear in the OIF list, except for AC1 itself.
                   <!-- (a) AC1 itself, and (b) any AC -->
                   <!-- that is attached to the same segment as AC1. -->
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> also be delivered to any other
                   EVPN&nbhy;PEs
                   EVPN-PEs that have interest in it.  This is achieved
                   as follows:
                   <list style="format %i.">
                    </t>
                    <ol spacing="normal" type="i"><li>
                        <t>
                       If (a) AR is being used, and (b) PE1 is an
                       AR&nbhy;LEAF,
                       AR-LEAF, and (c) the OIF list is non&nbhy;null, non-null,
                       PE1 MUST <bcp14>MUST</bcp14> send the frame to the AR&nbhy;REPLICATOR. AR-REPLICATOR.
                        </t>
                      </li>
                      <li>
                        <t>
                       Otherwise
                       Otherwise, the frame MUST <bcp14>MUST</bcp14> be sent on all tunnels in
                       the OIF list.
                        </t>
                   </list>
                 </t>
                      </li>
                    </ol>
                  </li>
                  <li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent to the local L3 routing instance
                   by being sent up the IRB interface of BD1.  It MUST NOT <bcp14>MUST NOT</bcp14>
                   be sent up any other IRB interfaces.
                    </t>
               </list>
             </t>
                  </li>
                </ol>
              </li>
              <li>
                <t>
               The frame was received by PE1 over a tunnel from another PE.
               (See <xref target="adv_tunnels"/> target="adv_tunnels" format="default"/> for the rules to determine
               the apparent source BD of a packet received from another PE.
               Note that if PE1 is not attached to the source BD, it will
               regard the SBD as the apparent source BD.)
               <list style="format %c.">
                </t>
                <ol spacing="normal" type="a"><li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent on all local ACs in the OIF list that
                   connect to BD1 and that are eligible (per <xref
                   target="ac_eligibility"/>) target="ac_eligibility" format="default"/>) to receive the frame.
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent up the IRB interface of the
                   apparent source BD. (Note that this may be the SBD.)  The
                   frame MUST NOT <bcp14>MUST NOT</bcp14> be sent up any other IRB interfaces.
                    </t>
                  </li>
                  <li>
                    <t>
                   If PE1 is not an AR&nbhy;REPLICATOR, AR-REPLICATOR, it MUST NOT <bcp14>MUST NOT</bcp14> send the
                   frame to any other EVPN&nbhy;PEs. EVPN-PEs.  However, if PE1 is an
                   AR&nbhy;REPLICATOR,
                   AR-REPLICATOR, it MUST <bcp14>MUST</bcp14> send the frame to all tunnels
                   in the OIF list, except for the tunnel over which the
                   frame was received.
                    </t>
               </list>
             </t>
                  </li>
                </ol>
              </li>
              <li>
                <t>
               The frame was received by PE1 from the BD1 IRB interface
               (i.e., the frame has been transmitted by PE1's L3 routing
               instance down the BD1 IRB interface), and BD1 is NOT the
               SBD.
               <list style="format %c.">
                </t>
                <ol spacing="normal" type="a"><li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent on all local ACs in the OIF list
                   that are eligible, as per <xref target="ac_eligibility"/>, target="ac_eligibility" format="default"/>,
				   to receive the frame.
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST NOT <bcp14>MUST NOT</bcp14> be sent to any other EVPN&nbhy;PEs. EVPN-PEs.
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST NOT <bcp14>MUST NOT</bcp14> be sent up any IRB interfaces.
                    </t>
               </list>
             </t>
                  </li>
                </ol>
              </li>
              <li>
                <t>
               The frame was received from the SBD IRB interface (i.e., has
               been transmitted by PE1's L3 routing instance down the SBD
               IRB interface).
               <list style="format %c.">
                </t>
                <ol spacing="normal" type="a"><li>
                    <t>
                   The frame MUST <bcp14>MUST</bcp14> be sent on all tunnels in the OIF list.
                   This causes the frame to be delivered to any other
                   EVPN&nbhy;PEs
                   EVPN-PEs that have interest in it.
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST NOT <bcp14>MUST NOT</bcp14> be sent on any local ACs.
                    </t>
                  </li>
                  <li>
                    <t>
                   The frame MUST NOT <bcp14>MUST NOT</bcp14> be sent up any IRB interfaces.
                    </t>
               </list>
             </t>
           </list>
         </t>
                  </li>
                </ol>
              </li>
            </ol>
          </section>
          <!-- oif_apply -->
     </section>
        <!-- iif_oif -->

        <!-- <section title="OIF List and Tunnels to other EVPN&nbhy;PEs"
             -->
        <!--          anchor="oif_tunnels"> -->
        <!--   <t> -->
        <!--     When using MPLS to tunnel an IP multicast frame from one PE to -->
        <!--     another, the frame will always carry a label that is specific to -->
        <!--     a BD.  We will refer to this as the "BD label".  In order to -->
        <!--     tunnel the packet, one first pushes on the ESI label, then the -->
        <!--     BD label.  These labels will be examined by the egress PE(s). -->
        <!--     Then one pushes on whatever additional labels are needed to -->
        <!--     transport the packet to the egress PE(s). -->
        <!--   </t> -->
        <!--   <t> -->
        <!--     <cref source=" ECR"> -->
        <!--       Did I get the ESI order right? -->
        <!--     </cref> -->
        <!--   </t> -->
        <!--   <t> -->
        <!--     This section specifies how the proper BD label is chosen for -->
        <!--     each type of tunnel.  It also discusses other procedures that -->
        <!--     are specific to particular tunnel types. -->
        <!--   </t> -->
        <!--   <t> -->
        <!--     <cref source=" ECR"> -->
        <!--       I guess we should also say how to do this with VXLAN. -->
        <!--     </cref> -->
        <!--   </t> -->
        <!--   <section title="Ingress Replication" anchor="oif_ir"> -->
        <!--     <t> -->
        <!--       This section applies when Ingress Replication is the technique -->
        <!-- used to tunnel IP multicast frames to other EVPN&nbhy;PEs of a
             -->
        <!--       Tenant Domain. -->
        <!--     </t> -->
        <!--     <t> -->
        <!-- When an ingress EVPN&nbhy;PE builds its L2 forwarding state for
             -->
        <!-- (S,G), it needs to determine all the egress EVPN&nbhy;PEs that
             are -->
        <!--       interested in (S,G).  How it does this is discussed in <xref -->
        <!--       target="cp_overview"/> and in <xref target="interest"/>. -->
        <!--     </t> -->
        <!--     <t> -->
        <!-- Then for each egress EVPN&nbhy;PE, the ingress PE needs to -->
        <!--       encapsulate the frame in an MPLS packet.  It first pushes on -->
        <!--       the ESI label.  It pushes on a BD label that was assigned by -->
        <!--       the egress PE.  This label will have been advertised in a PTA -->
        <!--       attached to an IMET route originated by that egress PE. -->
        <!--     </t> -->
        <!--     <t> -->
        <!--       To find the proper BD label, the ingress PE needs to examine -->
        <!--       the IMET routes received from the egress PE.  There are two -->
        <!--       cases to consider: -->
        <!--         <list style="numbers"> -->
        <!--           <t> -->
        <!--             There is an installed IMET route from the egress PE for -->
        <!--             the source BD of the IP multicast frame.  In this case, -->
        <!--             the label is taken from the PTA of that route. -->
        <!--           </t> -->
        <!--           <t> -->
        <!--             There is no installed IMET route from the egress PE for -->
        <!--             the source BD of the IP multicast frame.  In this case, -->
        <!--             there should be an installed IMET route from the egress -->
        <!--             PE for the SBD.  The label is taken from the PTA of that -->
        <!--             route. -->
        <!--           </t> -->
        <!--         </list> -->
        <!--     </t> -->
        <!--     <t> -->
        <!--       If neither case holds, there is an error, and the egress PE -->
        <!--       in question will not receive the (S,G) frame. -->
        <!--     </t> -->
        <!--     <t> -->
        <!--       The OIF list for a given multicast state must be constructed -->
        <!--       such that a copy of the frame is sent to each interested -->
        <!--       egress PE, with the proper BD label for that egress PE. -->
        <!--     </t> -->
        <!--     <t> -->
        <!--       When a frame is received by a given PE over an MPLS ingress -->
        <!--       replication tunnel, its top label will be label that was -->
        <!--       assigned by the receiving PE to a specific BD (possibly the -->
        <!--       SBD).  The receiving PE can thus infer the source BD of the -->
        <!--       frame. -->
        <!--     </t> -->
        <!--   </section> <!-\- oif_ir -\-> -->
        <!--   <section title="BIER" anchor="oif_bier"> -->
        <!--     <t> -->
        <!--       Please refer to <xref target="I-D.ietf-bier-evpn"/> for details. -->
        <!--     </t> -->
        <!--     <t> -->
        <!--       <cref source=" ECR"> -->
        <!--         I'm assuming that everything is covered in that draft, and -->
        <!--         we don't have to say anything in this draft.  What do you -->
        <!--         think? -->
        <!--       </cref> -->
        <!--     </t> -->
        <!--   </section> <!-\- oif_bier -\-> -->
        <!--   <section title="P2MP LSPs" anchor="oif_p2mp"> -->
        <!--   <section title="RSVP-TE P2MP" anchor="oif_rsvp"> -->
        <!--   <t> -->
        <!--     The procedure for using RSVP-TE P2MP to set up an inclusive -->
        <!--     tunnel is as follows. -->
        <!--   </t> -->
        <!--   <t> -->
        <!--     In case of RSVP-TE P2MP, the source NVE establishes a -->
        <!--     P2MP tunnel to all remote NVEs found through the SBD's IMET -->
        <!--     routes and advertises the tunnel in the IMET route for the -->
        <!--     source subnet. If tunnel aggregation is not used, a remote NVE -->
        <!--     attached to the source subnet binds the incoming tunnel branch -->
        <!--     to the source subnet, and a remote NVE that is not attached to -->
        <!--     the source subnet binds the incoming tunnel branch to the SBD. -->
        <!--   </t> -->
        <!--   <t> -->
        <!--     In case of BIER, or if tunnel aggregation is used for -->
        <!--     mLDP/RSVP-TE P2MP, a remote NVE binds the upstream allocated -->
        <!--     label in the IMET route for a source subnet to that subnet if it -->
        <!--     is present on the NVE. Otherwise it binds the label to the SBD. -->
        <!--   </t> -->

        <!-- </section> <!-\- oif_rsvp -\-> -->
        <!-- <section title="PIM or mLDP" anchor="oif_pim_mldp"> -->

        <!--   <t> -->
        <!--     In case of PIM/mLDP, a remote NVE joins the tunnel advertised in -->
        <!--     the IMET route for a source subnet. If tunnel aggregation is not -->
        <!--     used, a remote NVE attached to the source subnet binds the -->
        <!--     incoming tunnel branch to the source subnet, and a remote NVE -->
        <!--     that is not attached to the source subnet binds the incoming -->
        <!--     tunnel branch to the SBD. -->
        <!--   </t> -->
        <!-- </section> <!-\- oif-pim_mldp -\-> -->
        <!--   </section> <!-\- oif_p2mp -\-> -->

        <!-- </section> <!-\- oif_tunnels -\-> -->

    </section>
      <!-- l2_mcast_state -->

    <section title="Layer anchor="rpf" numbered="true" toc="default">
        <name>Layer 3 Forwarding State" anchor="rpf"> State</name>
        <t>
        If an EVPN&nbhy;PE EVPN-PE is performing IGMP/MLD procedures on the ACs of a
        given BD, it processes those messages at layer 2 to help form the
        layer 2 multicast state.  It also sends those messages up that BD's
        IRB interface to the L3 routing instance of a particular tenant
        domain.  This causes (C&nbhy;S,C&nbhy;G) the (C-S,C-G) or
        (C&nbhy;*,C&nbhy;G)
        (C-*,C-G) L3 state to be created/updated.
        </t>
        <t>
        A layer 3 multicast state has both an Input Interface (IIF) and an
        OIF list.
        </t>
        <t>
        For a (C&nbhy;S,C&nbhy;G) (C-S,C-G) state, if the source BD is present on the PE,
		the IIF is set to the IRB
        interface that attaches to that BD.  Otherwise  Otherwise, the IIF is set to the
        SBD IRB interface.
        </t>
        <!--t>
        <cref source=" ECR">
          And if S is an unknown address?  No one else seems bothered by the
          fact that we might need to do an RPF check against an unknown
          address, is there something I am not understanding?
        </cref>
      </t-->
      <t>
        For (C&nbhy;*,C&nbhy;G) (C-*,C-G) states, traffic can arrive from any BD, so
        the IIF needs to be set to a wildcard value meaning "any IRB
        interface".
        </t>
        <t>
        The OIF list of these states includes one or more of the IRB
        interfaces of the Tenant Domain.  In general, maintenance of the OIF
        list does not require any EVPN-specific procedures.  However, there
        is one EVPN-specific rule:
        <list>
          <t>
        </t>
            <t indent="3">
            If the IIF is one of the IRB interfaces (or the wild card wildcard
            meaning "any IRB interface"), then the SBD IRB interface MUST
            NOT <bcp14>MUST
            NOT</bcp14> be added to the OIF list.  Traffic originating from within a
            particular EVPN Tenant Domain must not be sent down the SBD IRB
            interface, as such traffic has already been distributed to all
            EVPN&nbhy;PEs
            EVPN-PEs attached to that Tenant Domain.
            </t>
        </list>
      </t>
        <t>
        Please also see <xref target="gen_prin"/>, target="gen_prin" format="default"/>, which states a
        modification of this rule for the case where OISM is interworking
        with external Layer 3 multicast routing.
        </t>
      </section>
      <!-- rpf -->
</section>
    <!-- mcast_state -->

<section title="Interworking anchor="no-OISM" numbered="true" toc="default">
      <name>Interworking with non&nbhy;OISM EVPN&nbhy;PEs" anchor="no-OISM"> Non-OISM EVPN-PEs</name>
      <t>
    It is possible that a given Tenant Domain will be attached to both OISM
    PEs and non&nbhy;OISM non-OISM PEs.  Inter&nbhy;subnet  Inter-subnet IP multicast should be
    possible and fully functional even if not all PEs attaching to a Tenant
    Domain can be upgraded to support OISM functionality.
      </t>
      <t>
    Note that the non&nbhy;OISM non-OISM PEs are not required to have IRB support, support or
    support for <xref target="RFC9251"/>.  It target="RFC9251" format="default"/>.  However, it is however advantageous for
    the non&nbhy;OISM non-OISM PEs to support <xref target="RFC9251"/>. target="RFC9251" format="default"/>.
      </t>
      <t>
    In this section, we will use the following terminology:
    <list style="symbols">
      <t>
        PE&nbhy;S: the
      </t>
      <dl spacing="normal" newline="false">
          <dt>PE-S:</dt> <dd>The ingress PE for an (S,G) flow.
      </t>
      <t>
        PE&nbhy;R: an flow.</dd>
          <dt>PE-R:</dt> <dd>An egress PE for an (S,G) flow.
      </t>
      <t>
        BD&nbhy;S: the flow.</dd>
          <dt>BD-S:</dt> <dd>The source BD for an (S,G) flow.  PE&nbhy;S  PE-S must have one
        or more ACs attached BD&nbhy;S, to BD-S, at least one of which attaches to
        host S.
      </t>
      <t>
        BD&nbhy;R: a S.</dd>
          <dt>BD-R:</dt> <dd>A BD that contains a host interested in the flow.  The
        host is attached to PE&nbhy;R PE-R via an AC that belongs to BD&nbhy;R.
      </t>
    </list>
  </t> BD-R.</dd>
        </dl>
      <t>
    To allow OISM PEs to interwork with non&nbhy;OISM non-OISM PEs, a given Tenant
    Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). Gateways (IPMGs)". An
    IPMG is an OISM PE with special responsibilities regarding the
    interworking between OISM and non&nbhy;OISM non-OISM PEs.
      </t>
<!-- IANA flag: IPMG flag -->
      <t>
    If a PE is functioning as an IPMG, it MUST <bcp14>MUST</bcp14> signal this fact by setting
    the "IPMG" IPMG flag in the Multicast Flags EC that it attaches to its IMET
    routes.  An IPMG SHOULD <bcp14>SHOULD</bcp14> attach this EC, with the IPMG flag set, to all
    IMET routes it originates.  Furthermore, if PE1 imports any IMET route from
    PE2 that has the EC present with the "IPMG" IPMG flag set, then the PE1 will
    assume that PE2 is an IPMG.
      </t>
      <t>
    An IPMG Designated Forwarder (IPMG&nbhy;DF) (IPMG-DF) selection procedure is used
    to ensure that, at any given time, that there is exactly one active
    IPMG&nbhy;DF
    IPMG-DF for any given BD. BD at any given time. Details of the IPMG&nbhy;DF IPMG-DF selection
    procedure are in <xref target="ipmg-df"/>. target="ipmg-df" format="default"/>. The IPMG&nbhy;DF IPMG-DF for a given
    BD, say BD&nbhy;S, BD-S, has special functions to perform when it receives
    (S,G) frames on that BD:
    <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>
        If the frames are from a non&nbhy;OISM PE&nbhy;S:
        <list style="symbols"> non-OISM PE-S:
          </t>
          <ul spacing="normal">
            <li>
              <t>
            The IPMG&nbhy;DF IPMG-DF forwards them to OISM PEs that do not attach to
            BD&nbhy;S
            BD-S but have interest in (S,G).
            <vspace/>
            <vspace/>
              </t>
              <t>
            Note that OISM PEs that do attach to BD&nbhy;S BD-S will have
            received the frames on the BUM tunnel from the non&nbhy;OISM
            PE&nbhy;S. non-OISM
            PE-S.
              </t>
            </li>
            <li>
              <t>
            The IPMG&nbhy;DF IPMG-DF forwards them to non&nbhy;OISM non-OISM PEs that have
            interest in (S,G) on ACs that do not belong to BD&nbhy;S.
            <vspace/>
            <vspace/> BD-S.
              </t>
              <t>
            Note that if a non&nbhy;OISM non-OISM PE has multiple BDs (other than
            BD&nbhy;S)
            BD-S) with interest in (S,G), it will receive one copy of
            the frame for each such BD. This is necessary because the
            non&nbhy;OISM
            non-OISM PEs cannot move IP multicast traffic from one BD
            to another.
              </t>
        </list>
      </t>
            </li>
          </ul>
        </li>
        <li>
          <t>
        If the frames are from an OISM PE, the IPMG&nbhy;DF IPMG-DF forwards them to
        non&nbhy;OISM
        non-OISM PEs that have interest in (S,G) on ACs that do not
        belong to BD&nbhy;S.
        <vspace/>
        <vspace/> BD-S.
          </t>
          <t>
        If a non&nbhy;OISM non-OISM PE has interest in (S,G) on an AC belonging to
        BD&nbhy;S,
        BD-S, it will have received a copy of the (S,G) frame,
        encapsulated for BD&nbhy;S, BD-S, from the OISM PE&nbhy;S. (See PE-S (see <xref
        target="imet-ir"/>.) target="imet-ir" format="default"/>). If the non&nbhy;OISM non-OISM PE has interest in (S,G)
        on one or more ACs belonging to BD&nbhy;R1,...,BD&nbhy;Rk BD-R1,...,BD-Rk where the
        BD&nbhy;Ri
        BD-Ri are distinct from BD&nbhy;S, BD-S, the IPMG&nbhy;DF IPMG-DF needs to
        send it a copy of the frame for each BD&nbhy;Ri.
      </t>
    </list> BD-Ri.
          </t>
        </li>
      </ul>
      <t>
    If an IPMG receives a frame on a BD for which it is not the
    IPMG&nbhy;DF,
    IPMG-DF, it just follows normal OISM procedures.
      </t>
      <t>
    This section specifies several sets of procedures:
    <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>
        the procedures that the IPMG&nbhy;DF IPMG-DF for a given BD needs to follow
        when receiving, on that BD, an IP multicast frame from a
        non&nbhy;OISM
        non-OISM PE;
          </t>
        </li>
        <li>
          <t>
        the procedures that the IPMG&nbhy;DF IPMG-DF for a given BD needs to follow
        when receiving, on that BD, an IP multicast frame from an OISM PE; and
          </t>
        </li>
        <li>
          <t>
        the procedures that an OISM PE needs to follow when receiving, on a
        given BD, an IP multicast frame from a non&nbhy;OISM non-OISM PE, when the
        OISM PE is not the IPMG&nbhy;DF IPMG-DF for that BD.
          </t>
    </list>
  </t>
        </li>
      </ul>
      <t>
    To enable OISM/non&nbhy;OISM OISM/non-OISM interworking in a given Tenant Domain, the
    Tenant Domain MUST <bcp14>MUST</bcp14> have some EVPN&nbhy;PEs EVPN-PEs that can function as IPMGs.
    An IPMG must be configured with the SBD.  It must also be configured
    with every BD of the Tenant Domain that exists on any of the
    non&nbhy;OISM
    non-OISM PEs of that domain.  (Operationally, it may be simpler to
    configure the IPMG with all the BDs of the Tenant Domain.)
      </t>
      <t>
    A non&nbhy;OISM
    Of course, a non-OISM PE of course only needs to be configured with BDs for
    which it has ACs.  An OISM PE that is not an IPMG only needs to be
    configured with the SBD and with the BDs for which it has ACs.
      </t>
      <t>
    An IPMG MUST <bcp14>MUST</bcp14> originate a wildcard SMET route (with (C&nbhy;*,C&nbhy;*) (C-*,C-*)
    in the NLRI) for each BD in the Tenant Domain.  This will cause it to
    receive all the IP multicast traffic that is sourced in the Tenant
    Domain. Note that non&nbhy;OISM non-OISM nodes that do not support <xref
    target="RFC9251"/> target="RFC9251" format="default"/> will send all the multicast traffic from a given
    BD to all PEs attached to that BD, even if those PEs do not originate an a
    SMET route.
      </t>
      <t>
    The interworking procedures vary somewhat depending upon whether packets
    are transmitted from PE to PE via Ingress Replication (IR) or via
    Point-to-Multipoint (P2MP) tunnels.  We In this section, we do not consider the use of BIER
    in this section,
    due to the low likelihood of there being a
    non&nbhy;OISM
    non-OISM PE that supports BIER.
      </t>
      <section title="IPMG anchor="ipmg-df" numbered="true" toc="default">
        <name>IPMG Designated Forwarder" anchor="ipmg-df"> Forwarder</name>
        <!-- <t> -->
    <!--   Each IPMG for a given Tenant Domain MUST <bcp14>MUST</bcp14> be configured with an "IPMG -->
    <!--   Ethernet Segment" for that domain.  This is an Ethernet Segment that -->
    <!--   has no ACs.  Conceptually, it represents the set of non-OISM PEs -->
    <!--   contained in the Tenant Domain.  In the control plane, this Ethernet -->
    <!--   Segment is identified by an ESI of Type 0; thus the ESI is an -->
    <!--   arbitrary 9-octet value, managed and configured by the operator. -->
    <!-- </t> -->
    <!-- <t> -->
    <!--   EVPN supports a number of procedures that can be used to select the -->
    <!--   Designated Forwarder (DF) for a particular BD on a particular Ethernet -->
    <!--   segment.  Some of the possible procedures can be found, e.g., in <xref -->
    <!--   target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, and <xref -->
    <!--   target="I-D.ietf-bess-evpn-pref-df"/>.  Whatever procedure is in use in a given -->
    <!--   deployment can be adapted to select an IPMG&nbhy;DF for a given BD, as -->
    <!--   follows. -->
    <!-- </t> -->
    <!-- <t> -->
    <!--   Each IPMG will originate an Ethernet Segment route for the IPMG dummy -->
    <!--   Ethernet segment.  It MUST <bcp14>MUST</bcp14> carry an ES-Import Route Target whose value -->
    <!--   is set to the high-order 6-octets of the IPMG ESI.  Thus only IPMGs -->
    <!--   will import the route. -->
    <!-- </t> -->
    <!-- <t> -->
    <!--   Once the set of IPMGs is known, it is also possible to determine the -->
    <!--   set of BDs supported by each IPMG.  The DF selection procedure can -->
    <!--   then be used to choose a DF for each BD.  (The conditions under which -->
    <!--   the IPMG&nbhy;DF for a given BD changes depends upon the DF selection -->
    <!--   algorithm that is in use.) -->
    <!-- </t> -->

<!-- IANA flag: IPMG flag -->
    <t>
      Every PE that is eligible for selection as an IPMG&nbhy;DF IPMG-DF for a
      particular BD originates both an IMET route for that BD and an
      SBD&nbhy;IMET
      SBD-IMET route.  As stated in <xref target="no-OISM"/>, target="no-OISM" format="default"/>, these
      SBD&nbhy;IMET
      SBD-IMET routes carry a Multicast Flags EC with the IPMG Flag flag
      set.
        </t>
        <t>
      These SBD&nbhy;IMET SBD-IMET routes SHOULD <bcp14>SHOULD</bcp14> also carry a DF Election EC.  The DF
      Election EC and its use is specified in <xref
      target="RFC8584"/>. target="RFC8584" format="default"/>.

<!--[rfced] Should "SHOULD not" be "SHOULD NOT"?

Original:
   When the route is
   originated, the
      AC&nbhy;DF AC-DF bit in the DF Election EC SHOULD not be set.
-->

      When the route is originated, the
      AC-DF bit in the DF Election EC <bcp14>SHOULD</bcp14> not be set.

<!--[rfced] Should "IPMSG-DF" be "IPMG-DF", as "IPMG" is used throughout
the document?

Original:
   This bit is not used when selecting an IPMSG&nbhy;DF, IPMSG-DF, i.e., it MUST be
   ignored by the receiver of an SBD&nbhy;IMET SBD-IMET route.
-->

      This bit
      is not used when selecting an IPMSG-DF, i.e., it <bcp14>MUST</bcp14> be ignored
      by the receiver of an SBD-IMET route.
        </t>
        <t>
      In the context of a given Tenant Domain, to select the IPMG&nbhy;DF IPMG-DF
      for a particular BD, say BD1, the IPMGs of the Tenant Domain perform
      the following procedure:
      <list style="symbols"> procedures:
        </t>
        <ul spacing="normal">
          <li>
            <t>
          From the set of received SBD&nbhy;IMET SBD-IMET routes for the given tenant
          domain, determine the candidate set of PEs that support IPMG
          functionality for that domain.
            </t>
          </li>
          <li>
            <t>
          Eliminate from
          From that candidate set set, eliminate any PEs from which an IMET route
          for BD1 has not been received.
            </t>
          </li>
          <li>
            <t>
          Select a DF Election election algorithm as specified in <xref
          target="RFC8584"/>. target="RFC8584" format="default"/>. Some of the possible algorithms
          can be found, e.g., in <xref target="RFC8584"/>, target="RFC8584" format="default"/>,
          <xref target="RFC7432"/>, target="RFC7432" format="default"/>, and <xref target="I-D.ietf-bess-evpn-pref-df"/>. target="I-D.ietf-bess-evpn-pref-df" format="default"/>.
            </t>
          </li>
          <li>
            <t>
          Apply the DF Election Algorithm election algorithm (see <xref
          target="RFC8584"/>) target="RFC8584" format="default"/>) to the candidate set of PEs.
          The "winner' "winner" becomes the IPMG-DF for BD1.
            </t>
      </list>
    </t>
          </li>
        </ul>
        <t>
      Note that even if a given PE supports MEG <xref target="mvpn"/>) (<xref target="mvpn" format="default"/>)
      and/or PEG (<xref target="pim_iwork"/>) target="pim_iwork" format="default"/>) functionality, as well as IPMG
      functionality, its SBD&nbhy;IMET SBD-IMET routes carry only one DF Election EC.
        </t>
      </section>
      <!-- ipmg_df -->

  <section title="Ingress Replication" anchor="non-OISM-IR"> anchor="non-OISM-IR" numbered="true" toc="default">
        <name>Ingress Replication</name>
        <t>
      The procedures of this section are used when Ingress Replication is
      used to transmit packets from one PE to another.
        </t>
        <t>
      When a non&nbhy;OISM PE&nbhy;S non-OISM PE-S transmits a multicast frame from
      BD&nbhy;S
      BD-S to another PE, PE&nbhy;R, PE&nbhy;S say PE-R, PE-S will use the
      encapsulation specified in the BD&nbhy;S BD-S IMET route that was
      originated by PE&nbhy;R. PE-R.  This encapsulation will include the label
      that appears in the "MPLS label" MPLS Label field of the PMSI Tunnel attribute Attribute
      (PTA) of the IMET route. If the tunnel type is VXLAN, the "label" is
      actually a Virtual Network Identifier (VNI); for other tunnel types,
      the label is an MPLS label.

<!--[rfced] May we remove "we will speak of" as shown below for clarity?

Original:
   In either case, we will speak of the transmitted frames as
   carrying a label that was assigned to a particular BD by
   the PE&nbhy;R PE-R to which the frame is being transmitted.

Perhaps:
   In either case, the transmitted frames carry a
   label that was assigned to a particular BD by
   the PE-R to which the frame is being transmitted.
-->

      In either case, we will speak of the
      transmitted frames as carrying a label that was assigned to a
      particular BD by the PE-R to which the frame is being
      transmitted.
        </t>
        <t>
      To support OISM/non&nbhy;OISM OISM/non-OISM interworking, an OISM PE&nbhy;R MUST PE-R <bcp14>MUST</bcp14>
      originate, for each of its BDs, both an IMET route and an S&nbhy;PMSI
      (C&nbhy;*,C&nbhy;*) A&nbhy;D (C-*,C-*)
      S-PMSI A-D route.  Note that even when IR is being
      used, interworking between OISM and non&nbhy;OISM non-OISM PEs requires the
      OISM PEs to follow the rules of <xref target="wc_spmsi"/>, target="wc_spmsi" format="default"/>, as modified
      below.
        </t>
        <t>
      Non&nbhy;OISM
      Non-OISM PEs will not understand S&nbhy;PMSI A&nbhy;D S-PMSI A-D routes.  So
      when a non&nbhy;OISM PE&nbhy;S non-OISM PE-S transmits an IP multicast frame with a
      particular source BD to an IPMG, it encapsulates the frame using the
      label specified in that IPMG's BD&nbhy;S BD-S IMET route.  (This is just
      the procedure of <xref target="RFC7432"/>.) target="RFC7432" format="default"/>.)
        </t>
        <t>
      The (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D (C-*,C-*) S-PMSI A-D route originated by a
      given OISM PE will have a PTA that specifies IR.
      <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
          If MPLS tunneling is being used, the MPLS label Label field SHOULD <bcp14>SHOULD</bcp14>
          contain a non&nbhy;zero non-zero value, and the LIR flag SHOULD <bcp14>SHOULD</bcp14> be zero.
          (The case where the MPLS label Label field is zero or the LIR flag is
          set is outside the scope of this document.)
            </t>
          </li>
          <li>
            <t>
          If the tunnel encapsulation is VXLAN, the MPLS label Label field MUST <bcp14>MUST</bcp14>
          contain a non&nbhy;zero non-zero value, and the LIR flag MUST <bcp14>MUST</bcp14> be zero.
            </t>
      </list>
    </t>
          </li>
        </ul>
        <t>
      When an OISM PE&nbhy;S PE-S transmits an IP multicast frame to an IPMG, it
      will use the label specified in that IPMG's (C&nbhy;*,C&nbhy;*)
      S&nbhy;PMSI A&nbhy;D (C-*,C-*)
      S-PMSI A-D route.
        </t>
        <t>
      When a PE originates both an IMET route and a (C&nbhy;*,C&nbhy;*)
      S&nbhy;PMSI A&nbhy;D (C-*,C-*)
      S-PMSI A-D route, the values of the MPLS label Label field in the
      respective PTAs must be distinct.  Further, each MUST <bcp14>MUST</bcp14> map uniquely (in
      the context of the originating PE) to the route's BD.
        </t>
        <!-- <t> -->
    <!-- In MPLS networks, it is also possible to originate an S&nbhy;PMSI A-D route -->
    <!--   whose PTA specifies a zero in the MPLS label field, and whose "PTA -->
    <!--   flags" field has the "Leaf Information Required" bit set.  This will -->
    <!--   cause each OISM PE to send a Leaf A-D route to each other OISM PE, -->
    <!--   specifying the label to use when transmitting to it a frame of the -->
    <!--   corresponding source BD. -->
    <!-- </t> -->
    <t>
      As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame
      can always tell by the label whether the frame's ingress PE is an OISM
      PE or a non&nbhy;OISM non-OISM PE.  When an IPMG receives a VXLAN-encapsulated
      IP multicast frame frame, it may need to determine the identity of the
      ingress PE from the outer IP encapsulation; it can then determine
      whether the ingress PE is an OISM PE or a non&nbhy;OISM non-OISM PE by looking at
      the IMET route from that PE.
        </t>
        <t>
      Suppose an IPMG receives an IP multicast frame from another
      EVPN&nbhy;PE
      EVPN-PE in the Tenant Domain, Domain and the IPMG is not the
      IPMG&nbhy;DF
      IPMG-DF for the frame's source BD.  Then  Then, the IPMG performs only
      the ordinary OISM functions; it does not perform the IPMG-specific
      functions for that frame.  In the remainder of this section, when we
      discuss the procedures applied by an IPMG when it receives an IP
      multicast frame, we are presuming that the source BD of the frame is a
      BD for which the IPMG is the IPMG&nbhy;DF. IPMG-DF.
        </t>
        <t>
      We have two basic cases to consider: (1) a frame's ingress PE is a
      non&nbhy;OISM node,
      non-OISM node and (2) a frame's ingress PE is an OISM node.
        </t>
        <section title="Ingress anchor="pe-s-non-oism" numbered="true" toc="default">
          <name>Ingress PE is non&nbhy;OISM" anchor="pe-s-non-oism"> Non-OISM</name>
          <t>
        In this case, a non&nbhy;OISM non-OISM PE, PE&nbhy;S, say PE-S, has received an (S,G)
        multicast frame over an AC that is attached to a particular BD,
        BD&nbhy;S.
        say BD-S.  By virtue of normal EVPN procedures, PE&nbhy;S PE-S has sent
        a copy of the frame to every PE&nbhy;R PE-R (both OISM and non&nbhy;OISM) non-OISM)
        in the Tenant Domain that is attached to BD&nbhy;S. BD-S.  If the
        non&nbhy;OISM
        non-OISM node supports <xref target="RFC9251"/>, target="RFC9251" format="default"/>, only PEs
        that have expressed interest in (S,G) receive the frame.  The IPMG
        will have expressed interest via a (C&nbhy;*,C&nbhy;*) (C-*,C-*) SMET route
        and thus receives the frame.
          </t>
          <t>
        Any OISM PE (including an IPMG) receiving the frame will apply
        normal OISM procedures.  As a result result, it will deliver the frame to
        any of its local ACs (in BD&nbhy;S BD-S or in any other BD) that have
        interest in (S,G).
          </t>
          <t>
        An OISM PE that is also the IPMG&nbhy;DF IPMG-DF for a particular BD, say
        BD&nbhy;S,
        BD-S, has additional procedures that it applies to frames
        received on BD&nbhy;S BD-S from non&nbhy;OISM non-OISM PEs:
        <list style="format %d. ">
          <t
          </t>
          <ol spacing="normal" type="1"><li anchor="non-oism-to-oism">
              <t>
            When the IPMG&nbhy;DF IPMG-DF for BD&nbhy;S BD-S receives an (S,G) frame from
            a non&nbhy;OISM non-OISM node, it MUST <bcp14>MUST</bcp14> forward a copy of the frame to
            every OISM PE that is NOT attached to BD&nbhy;S BD-S but has interest
            in (S,G).  The copy sent to a given OISM PE&nbhy;R PE-R must carry
            the label that PE&nbhy;R PE-R has assigned to the SBD in an
            S&nbhy;PMSI A&nbhy;D
            S-PMSI A-D route.  The IPMG MUST NOT <bcp14>MUST NOT</bcp14> do any IP
            processing of the frame's IP payload.  TTL decrement and other
            IP processing will be done by PE&nbhy;R, PE-R, per the normal OISM
            procedures. There is no need for the IPMG to include an ESI
            label in the frame's tunnel encapsulation, because it is already
            known that the frame's source BD has no presence on
            PE&nbhy;R.
            PE-R. There is also no need for the IPMG to modify the
            frame's MAC SA.
              </t>
          <t
            </li>
            <li anchor="non-oism-to-non-oism">
              <t>
            In addition, when the IPMG&nbhy;DF IPMG-DF for BD&nbhy;S BD-S receives an
            (S,G) frame from a non&nbhy;OISM non-OISM node, it may need to forward
            copies of the frame to other non&nbhy;OISM non-OISM nodes.  Before it
            does so, it MUST <bcp14>MUST</bcp14> decapsulate the (S,G) packet, packet and do the IP
            processing (e.g., TTL decrement).  Suppose PE&nbhy;R PE-R is a
            non&nbhy;OISM
            non-OISM node that has an AC to BD&nbhy;R, BD-R, where BD&nbhy;R BD-R
            is not the same as BD&nbhy;S, BD-S, and that AC has interest in (S,G).
            The IPMG must then encapsulate the (S,G) packet (after the IP
            processing has been done) in an Ethernet header.  The MAC SA
            field will have the MAC address of the IPMG's IRB interface for
            BD&nbhy;R.
            BD-R.  The IPMG then sends the frame to PE&nbhy;R. PE-R.  The
            tunnel encapsulation will carry the label that PE&nbhy;R PE-R
            advertised in its IMET route for BD&nbhy;R. BD-R.  There is no need to
            include an ESI label, as the source and destination BDs are
            known to be different.
            <vspace/>
            <vspace/>
              </t>
              <t>
            Note that if a non&nbhy;OISM PE&nbhy;R non-OISM PE-R has several BDs (other
            than BD&nbhy;S) BD-S) with local ACs that have interest in (S,G), the
            IPMG will send it one copy for each such BD.  This is necessary
            because the non&nbhy;OISM non-OISM PE cannot move packets from one BD to
            another.
              </t>
        </list>
      </t>
            </li>
          </ol>
          <t>
        There may be deployment scenarios in which every OISM PE is
        configured with every BD that is present on any non&nbhy;OISM non-OISM PE.
        In such scenarios, the procedures of item <xref target="non-oism-to-oism" format="counter"/> above will not actually
        result in the transmission of any packets.  Hence  Hence, if it is known a
        priori that this deployment scenario exists for a given tenant
        domain, the procedures of item <xref target="non-oism-to-oism" format="counter"/> above can be disabled.
          </t>
        </section>
        <!-- PE&nbhy;S-non&nbhy;OISM -->
    <section title="Ingress anchor="pe-s-oism" numbered="true" toc="default">
          <name>Ingress PE is OISM" anchor="pe-s-oism"> OISM</name>
          <t>
        In this case, an OISM PE, PE&nbhy;S, say PE-S, has received an (S,G) multicast
        frame over an AC that attaches to a particular BD, BD&nbhy;S. say BD-S.
          </t>
          <t>
        By virtue of receiving all the IMET routes for BD&nbhy;S,
        PE&nbhy;S BD-S,
        PE-S will know all the PEs attached to BD&nbhy;S. BD-S.  By virtue of
        normal OISM procedures:
        <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
            PE&nbhy;S
            PE-S will send a copy of the frame to every OISM PE&nbhy;R PE-R
            (including the IPMG) in the Tenant Domain that is attached to
            BD&nbhy;S
            BD-S and has interest in (S,G). The copy sent to a given
            PE&nbhy;R
            PE-R carries the label that that the PE&nbhy;R PE-R has assigned
            to BD&nbhy;S BD-S in its (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D (C-*,C-*) S-PMSI A-D
            route.
            <!-- or Leaf A-D route. -->
              </t>
            </li>
            <li>
              <t>
            PE&nbhy;S
            PE-S will also transmit a copy of the (S,G) frame to every
            OISM PE&nbhy;R PE-R that has interest in (S,G) but is not attached to
            BD&nbhy;S.
            BD-S.  The copy will contain the label that the PE&nbhy;R PE-R
            has assigned to the SBD.  (As specified in <xref target="pe-s-non-oism"/>, target="pe-s-non-oism" format="default"/>,
            an IPMG is assumed to have indicated interest in all multicast
            flows.)
              </t>
            </li>
            <li>
              <t>
            PE&nbhy;S
            PE-S will also transmit a copy of the (S,G) frame to every
            non&nbhy;OISM PE&nbhy;R
            non-OISM PE-R that is attached to BD&nbhy;S. BD-S.  It does
            this using the label advertised by that PE&nbhy;R PE-R in its IMET
            route for BD&nbhy;S.
          </t>
        </list> BD-S.
              </t>
            </li>
          </ul>
          <t>
        The PE&nbhy;Rs PE-Rs follow their normal procedures.  An OISM PE that
        receives the (S,G) frame on BD&nbhy;S BD-S applies the OISM procedures to
        deliver the frame to its local ACs, ACs as necessary.  A non&nbhy;OISM non-OISM
        PE that receives the (S,G) frame on BD&nbhy;S BD-S delivers the frame
        only to its local BD&nbhy;S ACs, BD-S ACs as necessary.
          </t>
          <t>
        Suppose that a non&nbhy;OISM PE&nbhy;R non-OISM PE-R has interest in (S,G) on a
        BD, BD&nbhy;R,
        BD that is different than BD&nbhy;S. BD-S, say BD-R.  If the
        non&nbhy;OISM PE&nbhy;R
        non-OISM PE-R is attached to BD&nbhy;S, BD-S, the OISM PE&nbhy;S PE-S
        will send it the original (S,G) multicast frame, but the
        non&nbhy;OISM PE&nbhy;R
        non-OISM PE-R will not be able to send the frame to ACs
        that are not in BD&nbhy;S. BD-S.  If PE&nbhy;R PE-R is not even attached to
        BD&nbhy;S,
        BD-S, the OISM PE&nbhy;S PE-S will not send it a copy of the frame
        at all, because PE&nbhy;R PE-R is not attached to the SBD.  In these
        cases, the IPMG needs to relay the (S,G) multicast traffic from OISM
        PE&nbhy;S
        PE-S to non&nbhy;OISM PE&nbhy;R. non-OISM PE-R.
          </t>
          <t>
        When the IPMG&nbhy;DF IPMG-DF for BD&nbhy;S BD-S receives an (S,G) frame from an
        OISM PE&nbhy;S, PE-S, it has to forward it to every non&nbhy;OISM
        PE&nbhy;R that non-OISM
        PE-R that has interest in (S,G) on a BD&nbhy;R BD-R that is
        different than BD&nbhy;S. BD-S.  The IPMG MUST <bcp14>MUST</bcp14> decapsulate the IP
        multicast packet, do the IP processing, re-encapsulate it for
        BD&nbhy;R
        BD-R (changing the MAC SA to the IPMG's own MAC address for
        BD&nbhy;R),
        BD-R), and send a copy of the frame to PE&nbhy;R. PE-R.  Note that a
        given non&nbhy;OISM PE&nbhy;R non-OISM PE-R will receive multiple copies of the
        frame,
        frame if it has multiple BDs on which there is interest in the
        frame.
          </t>
        </section>
        <!-- pe-s-oism -->
  </section>
      <!-- non&nbhy;OISM-IR -->

  <section title="P2MP Tunnels" anchor="non-oism-p2mp"> anchor="non-oism-p2mp" numbered="true" toc="default">
        <name>P2MP Tunnels</name>
        <t>
      When IR is used to distribute the multicast traffic among the
      EVPN&nbhy;PEs,
      EVPN-PEs, the procedures of described in <xref target="non-OISM-IR"/> target="non-OISM-IR" format="default"/> ensure
      that there will be no duplicate delivery of multicast traffic.  That
      is, no egress PE will ever send a frame twice on any given AC.  If
      P2MP tunnels are being used to distribute the multicast traffic, it is
      necessary to have additional procedures to prevent duplicate delivery.
        </t>
        <t>
      At the present time, it is not clear that there will be a use case in
      which OISM nodes need to interwork with non&nbhy;OISM non-OISM nodes that use
      P2MP tunnels.  If it is determined that there is such a use case,
      procedures for P2MP may be specified in a separate document.
        </t>
      </section>
      <!-- non-oism-p2mp -->
    <!-- <section title="P2MP Tunnels" anchor="non-oism-p2mp"> -->
    <!--       <t> -->
    <!--         <cref source=" ECR"> -->
    <!--           This section still preliminary, and may never actually be -->
    <!--           needed.  Hence it will probably be omitted from the next rev. -->
    <!--           We might want to say something short like "procedures will be -->
    <!--           provided if it is determined that this is a valid use case". -->
    <!--         </cref> -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         When IR is used to distribute the multicast traffic among the -->
    <!--         EVPN-PEs, the procedures of <xref target="non-OISM-IR"/> ensure -->
    <!--         that there will be no duplicate delivery of multicast traffic. -->
    <!--         That is, no egress PE will ever send a frame twice on any given -->
    <!--         AC.  If P2MP tunnels are being used to distribute the multicast -->
    <!--         traffic, it is necessary have additional procedures to prevent -->
    <!--         duplicate delivery. -->
    <!--         <list style="symbols"> -->
    <!--           <t> -->
    <!--             Every OISM PE (including the IPMGs) MUST <bcp14>MUST</bcp14> follow the -->
    <!--             procedures of <xref target="wc_spmsi"/> to advertise IP -->
    <!--             Multicast Tunnels that are distinct from the BUM tunnels. -->
    <!--             OISM PEs MUST NOT <bcp14>MUST NOT</bcp14> send IP multicast frames on the BUM -->
    <!--             tunnels. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--             The IPMG that is the DF for a given BD MUST <bcp14>MUST</bcp14> join all the IP -->
    <!--             multicast tunnels for that BD from OISM PEs.  Thus the IPMG -->
    <!--             for a given source BD, say BD-S, will receive each IP -->
    <!--             multicast frame whose source BD is BD-S and whose ingress PE -->
    <!--             is OISM. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--             Since non-OISM PEs do not join the IP multicast tunnels, IP -->
    <!--             multicast traffic from an OISM ingress PE to a set of -->
    <!--             non-OISM egress PEs must be relayed by the IPMG. -->
    <!--             <vspace/> -->
    <!--             <vspace/> -->
    <!--             Note that the IPMG does not relay IP multicast frames from -->
    <!--             an ingress OISM PE to any egress OISM PEs. -->
    <!--             <vspace/> -->
    <!--             <vspace/> -->
    <!--             Since non-OISM PEs expect to receive IP multicast frames on -->
    <!--             the BUM tunnels, the IPMG must advertise a tunnel for each -->
    <!--             BD that looks to non-OISM nodes as if it were an ordinary -->
    <!--             BUM tunnel, but is not joined by the OISM nodes.  We will -->
    <!--             refer to these as "non-OISM BUM tunnels". -->
    <!--           </t> -->
    <!--         </list> -->
    <!--       </t> -->

    <!--       <t> -->

    <!--         Consider an IP multicast frame whose ingress PE is non-OISM -->
    <!--         and whose source BD is BD-S. -->
    <!--         <list style="symbols"> -->
    <!--           <t> -->
    <!--             The procedures of <xref target="RFC7432"/> will cause the -->
    <!--             frame to be sent to all other PEs (OISM or non-OISM) that -->
    <!--             attach to BD-S. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--             If the frame has any non-OISM egress PEs with receivers that -->
    <!--             are in BD-R, where BD-R is different than BD-S, the IPMG -->
    <!--             must relay the frame to the egress non-OISM PEs.  It does -->
    <!--             this by doing the IP processing of the frame's IP multicast -->
    <!--             packet, and then re-encapsulating the packet for BD-R. -->
    <!--             After re-encapsulation, the MAC SA field of the Ethernet -->
    <!--             header carries the MAC address used by the IPMG itself in -->
    <!--             BD-R.  Then the frame is transmitted on the non-OISM BUM -->
    <!--             tunnel for BD-R. -->
    <!--             <vspace/> -->
    <!--             <vspace/> -->
    <!--             Note that if a non-OISM egress PE has receivers on BD-R1 -->
    <!--             and BD-R2, neither of which is BD-S, the egress PE will -->
    <!--             receive two copies of the frame, one on the non-OISM BUM -->
    <!--             tunnel for BD-R1, and one on the non-OISM BUM tunnel for -->
    <!--             BD-R2.  This is necessary because the non-OISM PEs cannot -->
    <!--             route frames from one BD to another. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--               OISM PEs MUST <bcp14>MUST</bcp14> join all the IP multicast tunnels -->
    <!--               advertised by other OISM PEs, including those -->
    <!--               advertised by the IPMG.  When an OISM PE joins the IP -->
    <!--               multicast tunnel for a given BD: -->
    <!--               <list style="symbols"> -->
    <!--                 <t> -->
    <!--                   If the PE is attached to that BD, it associates the -->
    <!--                   tunnel with that BD. -->
    <!--                 </t> -->
    <!--                 <t> -->
    <!--                   If the PE is not attached to that BD, it associates -->
    <!--                   the tunnel with the SBD. -->
    <!--                 </t> -->
    <!--               </list> -->
    <!--             </t> -->
    <!--             <t> -->
    <!--               Recall that when the IPMG (or any other OISM node) uses an -->
    <!--               S-PMSI A-D route to advertise a tunnel in a particular BD, the -->
    <!--               route carries an RT and an Ethernet Tag ID that together -->
    <!--               identify the BD. An OISM PE uses the RT and Tag ID to -->
    <!--               determine whether the route is for one of the BDs to -->
    <!--               which the PE is attached. -->
    <!--             </t> -->
    <!--             <t> -->
    <!--               When the IPMG receives an IP multicast frame on BD-S from -->
    <!--               a non-OISM ingress PE, it relays the frame unchanged on -->
    <!--               its IP multicast tunnel for BD-S.  This will carry the -->
    <!--               frame to all OISM PEs that have interest in it. -->
    <!--             </t> -->
    <!--             <t> -->
    <!--               When an OISM PE receives an IP multicast frame on the -->
    <!--               IP multicast tunnel from an IPMG, and the OISM PE has -->
    <!--               associated that frame with BD-S, it discards the frame. -->
    <!--               Otherwise, it follows the normal OISM procedures for -->
    <!--               frames received on an SBD tunnel. -->
    <!--               <vspace/> -->
    <!--               <vspace/> -->
    <!--               Note that if the BD-S IP multicast tunnel from the IPMG is -->
    <!--               an MPLS P2MP LSP, and if the PTA describing that tunnel -->
    <!--               has a zero in the MPLS Label field, then an OISM PE -->
    <!--               attached to BD-S SHOULD NOT join the tunnel. -->
    <!--             </t> -->
    <!--         </list> -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         In order for these procedures to work, the IPMG may need to -->
    <!--         advertise two BUM tunnels for each BD in the tenant domain: -->
    <!--         <list style="format %d. "> -->
    <!--           <t> -->
    <!--             Its "ordinary" BUM tunnel for the given BD, advertised -->
    <!--             in an IMET route for that BD.  This tunnel will be -->
    <!--             joined by all PEs (OISM and non-OISM) attached to the -->
    <!--             given BD.  The IPMG will use this tunnel only for -->
    <!--             transmitting BUM traffic that it receives from those of -->
    <!--             its own ACs attaching to the given BD. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--             A "non-OISM relay BUM tunnel" for the given BD.  This is -->
    <!--             advertised in a second IMET route for that BD.  This -->
    <!--             second IMET route MUST <bcp14>MUST</bcp14> have a different RD and MUST <bcp14>MUST</bcp14> have -->
    <!--             a different "originating router's IP address".  It MUST <bcp14>MUST</bcp14> -->
    <!--             carry a flag or an extended community [to be determined] -->
    <!--             meaning "non-OISM-only". -->
    <!--             <vspace/> -->
    <!--             <vspace/> -->
    <!--             Non-OISM nodes will join this tunnel, since it looks to them -->
    <!--             like an ordinary BUM tunnel.  OISM nodes will not join it, -->
    <!--             since it is marked "non-OISM-only". -->
    <!--             <vspace/> -->
    <!--             <vspace/> -->
    <!--             When the IPMG needs to relay IP multicast traffic from an -->
    <!--             ingress PE (other than the IPMG itself) to a set of non-OISM -->
    <!--             egress PEs, it sends the traffic on the non-OISM BUM -->
    <!--             tunnel. Note that there is a different non-OISM BUM tunnel -->
    <!--             for each BD. -->
    <!--           </t> -->
    <!--         </list> -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         If the IPMG does not have any ACs, it need not advertise an -->
    <!--         "ordinary BUM tunnel". -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         The IPMG must also advertise an "OISM-only relay tunnel" in an -->
    <!--         S-PMSI A-D route.  These tunnels can be advertised in (C-*,C-*) -->
    <!--         S-PMSI A-D routes or in more specific S-PMSI A-D routes.  The -->
    <!--         routes advertising these tunnels must be marked with a flag or -->
    <!--         EC that identifies them as being OISM-only relay tunnels from an -->
    <!--         IPMG.  Since these tunnels are advertised in S-PMSI A-D routes, -->
    <!--         and non-OISM nodes do not understand S-PMSI A-D routes, the -->
    <!--         non-OISM nodes will not join these tunnels. -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         The non-OISM nodes will advertise P2MP tunnels in their IMET -->
    <!--         routes.  These are their "BUM tunnels".  Suppose the IPMG gets -->
    <!--         an (S,G) multicast frame from the BD-S BUM tunnel of a non-OISM -->
    <!--         PE-S. -->
    <!--         <list style="symbols"> -->
    <!--           <t> -->
    <!--             If there are any non-OISM PEs with interest in (S,G) on a -->
    <!--             given BD, say BD-R, where BD-R is not the same as BD-S, then -->
    <!--             the IPMG does the IP processing of the (S,G) multicast -->
    <!--             packet, changes the MAC SA of the Ethernet encapsulation to -->
    <!--             its own MAC address, and sends the frame on the non-OISM -->
    <!--             relay BUM tunnel for BD-R. -->
    <!--           </t> -->
    <!--           <t> -->
    <!--             If there are any OISM PEs with interest in (S,G) on a given -->
    <!--             BD, say BD-R, where BD-R is not the same as BD-S, then the -->
    <!--             IPMG sends the frame on the OISM-only relay tunnel for BD-R -->
    <!--             that it uses for sending (S,G) traffic.  The IPMG MUST NOT <bcp14>MUST NOT</bcp14> -->
    <!--             do the IP processing and MUST NOT <bcp14>MUST NOT</bcp14> modify the MAC SA of the -->
    <!--             frame. -->
    <!--           </t> -->
    <!--         </list> -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         If an IPMG has ACs attaching to a particular BD, it MUST NOT <bcp14>MUST NOT</bcp14> -->
    <!--         transmit those frames on an OISM-only relay tunnel.  Instead, -->
    <!--         the IPMG will need to originate a different set of routes to -->
    <!--         advertise the tunnels for carrying packets from its ACs. These -->
    <!--         routes have a different RD and a different originating router IP -->
    <!--         address than the relay tunnels. -->
    <!--       </t> -->
    <!--       <t> -->
    <!--         We have assumed above that non-OISM nodes will not recognize -->
    <!--         S-PMSI A-D routes.  If we want to accommodate a future where -->
    <!--         non-OISM nodes do support S-PMSI A-D routes, an EC or flag would -->
    <!--         have to be used to distinguish the OISM-only IP multicast -->
    <!--         tunnels from the ordinary IP multicast tunnels.   -->
    <!--         The non-OISM nodes would be upgraded to understand this flag or -->
    <!--         EC when they are upgraded to understand S-PMSI A-D routes.             -->
    <!--       </t> -->
    <!--     </section>  -->

</section>
    <!-- no-OISM -->

<section title="Traffic anchor="external" numbered="true" toc="default">
      <name>Traffic to/from Outside the EVPN Tenant Domain"
         anchor="external"> Domain</name>
      <t>
    In this section, we discuss scenarios where a multicast source outside a
    given EVPN Tenant Domain sends traffic to receivers inside the domain
    (as well as, possibly, to receivers outside the domain).  This requires
    the OISM procedures to interwork with various layer 3 multicast routing
    procedures.
      </t>
      <t>
    We assume in
     In this section section, we assume that the Tenant Domain is not being used as an
    intermediate transit network for multicast traffic; that is, we do not
    consider the case where the Tenant Domain contains multicast routers
    that will receive traffic from sources outside the domain and forward
    the traffic to receivers outside the domain.  The transit scenario is
    considered in <xref target="pim"/>. target="pim" format="default"/>.
      </t>
      <t>
    We can divide the non-transit scenarios into two classes:
    <list style="format %d. ">
      </t>
      <ol spacing="normal" type="1"><li>
          <t>
        One or more of the EVPN PE routers provide the functionality needed
        to interwork with layer 3 multicast routing procedures.
          </t>
        </li>
        <li>
          <t>
        A single BD in the Tenant Domain contains external multicast routers
        ("tenant multicast routers"), and those tenant multicast routers are
        used to interwork, on behalf of the entire Tenant Domain, with layer
        3 multicast routing procedures.
          </t>
    </list>
  </t>
        </li>
      </ol>
      <section title="Layer anchor="evpn-pe-l3-iwork" numbered="true" toc="default">
        <name>Layer 3 Interworking via EVPN OISM PEs" anchor="evpn-pe-l3-iwork"> PEs</name>
        <section title="General Principles" anchor="gen_prin"> anchor="gen_prin" numbered="true" toc="default">
          <name>General Principles</name>
          <t>
        Sometimes it is necessary to interwork an EVPN Tenant Domain with an
        external layer 3 multicast domain (the "external domain"), e.g.,
		a PIM or MVPN domain.  This is
        needed to allow EVPN tenant systems to receive multicast traffic
        from sources ("external sources") outside the EVPN Tenant Domain.
        It is also needed to allow receivers ("external receivers") outside
        the EVPN Tenant Domain to receive traffic from sources inside the
        Tenant Domain.
          </t>
          <t>
        In order to allow interworking between an EVPN Tenant Domain and an
        external domain, one or more OISM PEs must be "L3 Gateways".  An L3
        Gateway participates both in the OISM procedures and in the L3
        multicast routing procedures of the external domain, as shown in
	the following figure.

<!--[rfced] Since the artwork in Section 6.1.1 is referred to as a
"figure" in the running text, we formatted it as such and added
"L3 Gateway" as the title.  Please review and let us know if this
is agreeable or if any updates are needed.
-->
          </t>
	  <figure>
    <artwork>
	  <name>L3 Gateway</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                  src1                       rcvr1
                  |                          |
                  R1           RP            R2

                            PIM/MVPN
                             domain
                             Domain
                 +---+                      +---+
            -----|GW1|----------------------|GW2|----
                 +---+                      +---+
                  | \ \                    / / |
                  |  \ \                  / /  |
                BD1 BD2 SBD            SBD BD2 BD1

                           EVPN Domain

                        SBD            SBD
                       /                  \
                      /                    \
                 +---+                      +---+
                 |PE1|                      |PE2|
                 +---+                      +---+
                  | \                       / |
                 BD1 BD2                  BD2 BD1
                  |   |                    |  |
                 src2 rcvr2              src3 rcvr3
	</artwork>
    </figure>
      </t>
	]]></artwork></figure>
          <t>
        An L3 Gateway that has interest in receiving (S,G) traffic must be
        able to determine the best route to S.  If an L3 Gateway has
        interest in (*,G), it must be able to determine the best route to
        G's RP.  In these interworking scenarios, the L3 Gateway must be
        running a layer 3 unicast routing protocol.  Via this protocol, it
        imports unicast routes (either IP routes or VPN&nbhy;IP VPN-IP routes) from
        routers other than EVPN PEs.  And since there may be multicast
        sources inside the EVPN Tenant Domain, the EVPN PEs also need to
        export, either as IP routes or as VPN&nbhy;IP VPN-IP routes (depending upon
        the external domain), unicast routes to those sources.
          </t>
          <t>
        When selecting the best route to a multicast source or RP, an L3
        Gateway might have a choice between an EVPN route and an
        IP/VPN&nbhy;IP
        IP/VPN-IP route.  When such a choice exists, the L3 Gateway
        SHOULD
        <bcp14>SHOULD</bcp14> always prefer the EVPN route.  This will ensure that when
        traffic originates in the Tenant Domain and has a receiver in the
        Tenant Domain, the path to that receiver will remain within the EVPN
        Tenant Domain, even if the source is also reachable via a routed
        path.  This also provides protection against sub&nbhy;optimal sub-optimal
        routing that might occur if two EVPN PEs export IP/VPN&nbhy;IP IP/VPN-IP
        routes and each imports the other's IP/VPN-IP routes.
          </t>
          <t>
        <xref target="rpf"/> target="rpf" format="default"/> discusses the way layer 3 multicast states are
        constructed by OISM PEs.  These layer 3 multicast states have IRB
        interfaces as their IIF and OIF list entries, entries and are the basis for
        interworking OISM with other layer 3 multicast procedures such as
        MVPN or PIM.  From the perspective of the layer 3 multicast
        procedures running in a given L3 Gateway, an EVPN Tenant Domain is a
        set of IRB interfaces.
          </t>
          <t>
        When interworking an EVPN Tenant Domain with an external domain, the
        L3 Gateway's layer 3 multicast states will not only have IRB
        interfaces as IIF and OIF list entries, entries but also other "interfaces"
        that lead outside the Tenant Domain.  For example, when interworking
        with MVPN, the multicast states may have MVPN tunnels as well as IRB
        interfaces as IIF or OIF list members.  When interworking with PIM,
        the multicast states may have PIM-enabled non&nbhy;IRB non-IRB interfaces as
        IIF or OIF list members.
          </t>
          <t>
        As long as a Tenant Domain is not being used as an intermediate
        transit network for IP multicast traffic, it is not necessary to
        enable PIM on its IRB interfaces.
          </t>
          <t>
        In general, an L3 Gateway has the following responsibilities:
        <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
            It exports, to the external domain, unicast routes to those
            multicast sources in the EVPN Tenant Domain that are locally
            attached to the L3 Gateway.
              </t>
            </li>
            <li>
              <t>
            It imports, from the external domain, unicast routes to
            multicast sources that are in the external domain.
              </t>
            </li>
            <li>
              <t>
            It executes the procedures necessary to draw externally sourced
            multicast traffic that is of interest to locally attached
            receivers in the EVPN Tenant Domain.  When such traffic is
            received, the traffic is sent down the IRB interfaces of the BDs
            on which the locally attached receivers reside.
              </t>
        </list>
      </t>
            </li>
          </ul>
          <t>
        One of the L3 Gateways in a given Tenant Domain becomes the "DR" for
        the SBD. (See SBD (see <xref target="dr_selection"/>.) target="dr_selection" format="default"/>).  This L3 gateway has
        the following additional responsibilities:
        <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
            It exports, to the external domain, unicast routes to multicast
            sources in the EVPN Tenant Domain that are not locally
            attached to any L3 gateway.
              </t>
            </li>
            <li>
              <t>
            It imports, from the external domain, unicast routes to multicast
            sources that are in the external domain.
              </t>
            </li>

<!--[rfced] Does "that are not locally attached to an L3 gateway" describe
"externally sourced multicast traffic"? If so, may we clarify this text
as follows?

Original:
   *  It executes the procedures necessary to draw externally sourced
      multicast traffic that is of interest to receivers in the EVPN
      Tenant Domain that are not locally attached to an L3 gateway.

Perhaps:
   *  It executes the procedures necessary to draw externally sourced
      multicast traffic that is of interest to receivers in the EVPN
      Tenant Domain and that is not locally attached to an L3 gateway.
-->

            <li>
              <t>
            It executes the procedures necessary to draw externally sourced
            multicast traffic that is of interest to receivers in the EVPN
            Tenant Domain that are not locally attached to an L3 gateway.
            When such traffic is received, the traffic is sent down the SBD
            IRB interface.  OISM procedures already described in this
            document will then ensure that the IP multicast traffic gets
            distributed throughout the Tenant Domain to any EVPN PEs that
            have interest in it. Thus Thus, to an OISM PE that is not an L3
            gateway
            gateway, the externally sourced traffic will appear to have been
            sourced on the SBD.
              </t>
        </list>
      </t>
            </li>
          </ul>
          <t>
        In order for this to work, some special care is needed when an L3
        gateway creates or modifies a layer 3 (*,G) multicast state.
        Suppose group G has both external sources (sources outside the EVPN
        Tenant Domain) and internal sources (sources inside the EVPN tenant
        domain). <xref target="rpf"/> target="rpf" format="default"/> states that when there are internal
        sources, the SBD IRB interface must not be added to the OIF list of
        the (*,G) state.  Traffic from internal sources will already have
        been delivered to all the EVPN PEs that have interest in it.
        However, if the OIF list of the (*,G) state does not contain its SBD
        IRB interface, then traffic from external sources will not get
        delivered to other EVPN PEs.
          </t>
          <t>

<!--rfced] For clarity, may we update "from other than" to "that is
not from" (option A) or "that is from an interface other than
IRB" (option B)? Please let us know your preference.

Original:
   When an L3 gateway
   receives (S,G) traffic from other than an IRB interface, and the
   traffic corresponds to a layer 3 (*,G) state, the L3 gateway can
   create (S,G) state.

Perhaps A:
   When an L3 gateway
   receives (S,G) traffic that is not from an IRB interface, and the
   traffic corresponds to a layer 3 (*,G) state, the L3 gateway can
   create (S,G) state.
or

Perhaps B:
   When an L3 gateway
   receives (S,G) traffic that is from an interface other than IRB,
   and the traffic corresponds to a layer 3 (*,G) state, the L3
   gateway can create (S,G) state.
-->

        One way of handling this is the following.  When an L3 gateway
        receives (S,G) traffic from other than an IRB interface, and the
        traffic corresponds to a layer 3 (*,G) state, the L3 gateway can
        create (S,G) state.  The IIF will be set to the external interface
        over which the traffic is expected.  The OIF list will contain the
        SBD IRB interface, as well as the IRB interfaces of any other BDs
        attached to the PEG DR that have locally attached receivers with
        interest in the (S,G) traffic.  The (S,G) state will ensure that the
        external traffic is sent down the SBD IRB interface. The following
        text will assume this procedure; however however, other implementation
        techniques may also be possible.
          </t>
          <t>
        If a particular BD
        <!-- (other than the SBD) -->
        is attached to several L3
        Gateways, one of the L3 Gateways becomes the DR for that BD.  (See BD (see
        <xref target="dr_selection"/>.) target="dr_selection" format="default"/>).  If the interworking scenario
        requires FHR functionality, it is generally the DR for a particular
        BD that is responsible for performing that functionality on behalf
        of the source hosts on that BD.  (E.g., BD (e.g., if the interworking scenario
        requires that PIM Register messages be sent by an FHR, the DR for a
        given BD would send the PIM Register messages for sources on that
        BD.)  Note though
        BD).  Although, note that the DR for the SBD does not perform FHR
        functionality on behalf of external sources.
          </t>
          <t>
        An optional alternative is to have each L3 gateway perform FHR
        functionality for locally attached sources.  Then  Then, the DR would only
        have to perform FHR functionality on behalf of sources that are
        locally attached to itself AND sources that are not attached to any
        L3 gateway.
          </t>
          <t>
        N.B.:
        NB: If it is possible that more than one BD contains a tenant
        multicast router, then a PE receiving an a SMET route for that BD MUST
        NOT <bcp14>MUST
        NOT</bcp14> reconstruct IGMP/MLD Join Reports from the SMET route, route and MUST NOT <bcp14>MUST NOT</bcp14>
        transmit any such IGMP/MLD Join Reports on its local ACs attaching to
        that BD. Otherwise, multicast traffic may be duplicated.
          </t>
        </section>
        <!-- gen_prin -->

  <section title="Interworking anchor="mvpn" numbered="true" toc="default">
          <name>Interworking with MVPN" anchor="mvpn"> MVPN</name>
          <t>
      In this section, we specify the procedures necessary to allow EVPN PEs
      running OISM procedures to interwork with L3VPN PEs that run BGP-based
      MVPN <xref target="RFC6514"/> target="RFC6514" format="default"/> procedures.  More specifically, the
      procedures herein allow a given EVPN Tenant Domain to become part of
      an L3VPN/MVPN, L3VPN/MVPN and support multicast flows where either:
      <list style="symbols"> either of the following occurs:
          </t>
          <ul spacing="normal">
            <li>
              <t>
          The source of a given multicast flow is attached to an Ethernet
          segment whose BD is part of an EVPN Tenant Domain, and one or
          more receivers of the flow are attached to the network via
          L3VPN/MVPN.  (Other receivers may be attached to the network via
          EVPN.)
              </t>
            </li>
            <li>
              <t>
          The source of a given multicast flow is attached to the network
          via L3VPN/MVPN, and one or more receivers of the flow are attached
          to an Ethernet segment that is part of an EVPN tenant
          domain. (Other receivers may be attached via L3VPN/MVPN.)
              </t>
      </list>
    </t>
            </li>
          </ul>
          <t>
      In this interworking model, existing L3VPN/MVPN PEs are unaware that
      certain sources or receivers are part of an EVPN Tenant Domain.  The
      existing L3VPN/MVPN nodes run only their standard procedures and are
      entirely unaware of EVPN.  Interworking is achieved by having some or
      all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN
      procedures, as detailed in the following sub-sections. subsections.
          </t>
          <t>
      In this section, we assume that there are no tenant multicast routers
      on any of the EVPN-attached Ethernet segments.  (There  (Of course, there may of course
      be multicast routers in the L3VPN.)  Consideration of the case where
      there are tenant multicast routers is deferred till addressed in <xref
      target="pim"/>.) target="pim" format="default"/>.
          </t>
          <!-- <section title="Model of Operation" anchor="iwork_model"> -->
    <t>
      To support MVPN/EVPN interworking, we introduce the notion of an
      MVPN/EVPN Gateway, or MEG. Gateway (MEG).
          </t>
          <t>
      A MEG is an L3 Gateway (see <xref target="gen_prin"/>), hence target="gen_prin" format="default"/>); hence, it is both
      an OISM PE and an L3VPN/MVPN PE.  For a given EVPN Tenant Domain, it
      will have an IP&nbhy;VRF. IP-VRF. If the Tenant Domain is part of an
      L3VPN/MVPN, the IP&nbhy;VRF IP-VRF also serves as an L3VPN VRF <xref
      target="RFC4364"/>. target="RFC4364" format="default"/>.  The IRB interfaces of the IP&nbhy;VRF IP-VRF are
      considered to be "VRF interfaces" of the L3VPN VRF.  The L3VPN VRF may
      also have other local VRF interfaces that are not EVPN IRB interfaces.
          </t>
          <t>
      The VRF on the MEG will import VPN&nbhy;IP VPN-IP routes <xref
      target="RFC4364"/> target="RFC4364" format="default"/> from other L3VPN Provider Edge (PE) PE routers.  It
      will also export VPN&nbhy;IP VPN-IP routes to other L3VPN PE routers.  In
      order to do so, it must be appropriately configured with the Route
      Targets used in the L3VPN to control the distribution of the
      VPN&nbhy;IP
      VPN-IP routes.  These  In general, these Route Targets will in general be different
      than the Route Targets used for controlling the distribution of EVPN
      routes, as there is no need to distribute EVPN routes to L3VPN-only
      PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs.
          </t>
          <t>
      Note that the RDs in the imported VPN&nbhy;IP VPN-IP routes will not
      necessarily conform to the EVPN rules (as specified in <xref
      target="RFC7432"/>) target="RFC7432" format="default"/>) for creating RDs.  Therefore  Therefore, a MEG MUST NOT <bcp14>MUST NOT</bcp14> expect
      the RDs of the VPN&nbhy;IP VPN-IP routes to be of any particular format other
      than what is required by the L3VPN/MVPN specifications.
          </t>
          <t>
      The VPN&nbhy;IP VPN-IP routes that a MEG exports to L3VPN are subnet routes
      and/or host routes for the multicast sources that are part of the EVPN
      tenant domain.  The exact set of routes that need to be exported is
      discussed in <xref target="e2m"/>. target="e2m" format="default"/>.
          </t>
<!-- IANA flag: MEG flag -->
          <t>
      Each IMET route originated by a MEG SHOULD <bcp14>SHOULD</bcp14> carry a Multicast Flags
      Extended Community with the "MEG" MEG flag set, indicating that the
      originator of the IMET route is a MEG. However, PE1 will consider PE2
      to be a MEG if PE1 imports at least one IMET route from PE2 that
      carries the Multicast Flags EC with the MEG flag set.
          </t>
          <t>
      All the MEGs of a given Tenant Domain attach to the SBD of that
      domain, and one of them is selected to be the SBD's Designated Router
      (the "MEG SBD&nbhy;DR") SBD-DR") for the domain.  The selection procedure is
      discussed in <xref target="dr_selection"/>. target="dr_selection" format="default"/>.
          </t>
          <t>
      In this model of operation, MVPN procedures and EVPN procedures are
      largely independent.  In particular, there is no assumption that MVPN
      and EVPN use the same kind of tunnels.  Thus  Thus, no special procedures are
      needed to handle the common scenarios where, e.g., EVPN uses VXLAN
      tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses Ingress
      Replication but MVPN uses MPLS P2MP tunnels.
          </t>
          <t>
      Similarly, no special procedures are needed to prevent duplicate data
      delivery on Ethernet segments that are multi&nbhy;homed. multihomed.
          </t>
          <t>
      The MEG does have some special procedures (described below) for
      interworking between EVPN and MVPN; these have to do with selection of
      the Upstream PE for a given multicast source, with the exporting of
      VPN&nbhy;IP routes,
      VPN-IP routes and with the generation of MVPN C&nbhy;multicast C-multicast
      routes triggered by the installation of SMET routes.
          </t>
          <section title="MVPN anchor="m2e" numbered="true" toc="default">
            <name>MVPN Sources with EVPN Receivers" anchor="m2e"> Receivers</name>
            <section title="Identifying anchor="mvpn_source" numbered="true" toc="default">
              <name>Identifying MVPN Sources" anchor="mvpn_source"> Sources</name>
              <t>
          Consider a multicast source S.  It is possible that a MEG will
          import both an EVPN unicast route to S and a VPN&nbhy;IP VPN-IP route (or
          an ordinary IP route), where the prefix length of each route is
          the same.  In order to draw (S,G) multicast traffic for any group
          G, the MEG SHOULD <bcp14>SHOULD</bcp14> use the EVPN route rather than the VPN&nbhy;IP VPN-IP
          or IP route to determine the "Upstream PE" (see section 5 of <xref
          target="RFC6513"/>). target="RFC6513" format="default" sectionFormat="of" section="5"/>).
              </t>
              <t>
          Doing so ensures that when an EVPN tenant system desires to
          receive a multicast flow from another EVPN tenant system, the
          traffic from the source to that receiver stays within the EVPN
          domain.  This prevents problems that might arise if there is a
          unicast route via L3VPN to S, S but no multicast routers along the
          routed path.  This also prevents problem that might arise as a
          result of the fact that the MEGs will import each others'
          VPN&nbhy;IP
          VPN-IP routes.
              </t>
              <t>
          In the <xref target="mvpn_join"/>, target="mvpn_join" format="default"/>, we describe the procedures to
          be used when the selected route to S is a VPN&nbhy;IP VPN-IP route.
              </t>
            </section>
            <!-- mvpn_source -->

      <section title="Joining anchor="mvpn_join" numbered="true" toc="default">
              <name>Joining a Flow from an MVPN Source" anchor="mvpn_join"> Source</name>
              <t>
          Consider a tenant system, say R, on a particular BD, say BD-R.  Suppose R
          wants to receive (S,G) multicast traffic, where source S is not
          attached to any PE in the EVPN Tenant Domain, Domain but is attached to
          an MVPN PE.
          <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>
              Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, BD-R
              and that segment is attached to PE1, where PE1 is a MEG.  PE1
              learns via IGMP/MLD listening that R is interested in (S,G).
              PE1 determines from its VRF that there is no route to S within
              the Tenant Domain (i.e., no EVPN RT-2 route matching on S's IP
              address),
              address) but that there is a route to S via L3VPN (i.e., the
              VRF contains a subnet or host route to S that was received as
              a VPN&nbhy;IP VPN-IP route).  Thus, PE1 thus originates (if it hasn't
              already) an MVPN C&nbhy;multicast C-multicast Source Tree Join(S,G) route.
              The route is constructed according to normal MVPN procedures.
              <vspace/>
              <vspace/>
                  </t>
                  <t>
              The layer 2 multicast state is constructed as specified in
              <xref target="l2_state"/>.
              <vspace/>
              <vspace/> target="l2_state" format="default"/>.
                  </t>
                  <t>
              In the layer 3 multicast state, the IIF is the appropriate
              MVPN tunnel, and the IRB interface to BD&nbhy;R BD-R is added to
              the OIF list.
              <vspace/>
              <vspace/>
                  </t>
                  <t>
              When PE1 receives (S,G) traffic from the appropriate MVPN
              tunnel, it performs IP processing of the traffic, traffic and then
              sends the traffic down its IRB interface to BD&nbhy;R. BD-R.
              Following normal OISM procedures, the (S,G) traffic will be
              encapsulated for Ethernet and sent on the AC to which R is
              attached.
                  </t>
                </li>
                <li>
                  <t>
              Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, BD-R
              and that segment is attached to PE1, where PE1 is an OISM PE
              but is NOT a MEG.  PE1 learns via IGMP/MLD listening that R is
              interested in (S,G). PE1 follows normal OISM procedures,
              originating an SBD-SMET route for (S,G); this route will be
              received by all the MEGs of the Tenant Domain, including the
              MEG SBD&nbhy;DR.  The SBD-DR.  From PE1's IMET routes, the MEG SBD&nbhy;DR SBD-DR can determine from PE1's
              IMET routes
	      whether or not PE1 is itself a MEG.  If PE1 is not a MEG,
              the MEG SBD&nbhy;DR SBD-DR will originate (if it hasn't already) an
              MVPN C&nbhy;multicast C-multicast Source Tree Join(S,G) route.  This will
              cause the MEG SBD&nbhy;DR SBD-DR to receive (S,G) traffic on an MVPN
              tunnel.
              <vspace/>
              <vspace/>
                  </t>
                  <t>
              The layer 2 multicast state is constructed as specified in
              <xref target="l2_state"/>.
              <vspace/>
              <vspace/> target="l2_state" format="default"/>.
                  </t>
                  <t>
              In the layer 3 multicast state, the IIF is the appropriate
              MVPN tunnel, and the IRB interface to the SBD is added to the
              OIF list.
              <vspace/>
              <vspace/>
                  </t>
                  <t>
              When the MEG SBD&nbhy;DR SBD-DR receives (S,G) traffic on an MVPN
              tunnel, it performs IP processing of the traffic, traffic and the then
              sends the traffic down its IRB interface to the SBD.
              Following normal OISM procedures, the traffic will be
              encapsulated for Ethernet and delivered to all PEs in the
              Tenant Domain that have interest in (S,G), including PE1.
                  </t>
                </li>
                <li>
                  <t>
              If R is on a multi&nbhy;homed multihomed Ethernet segment of BD&nbhy;R, BD-R,
              one of the PEs attached to the segment will be its DF
              (following normal EVPN procedures), and the DF will know (via
              IGMP/MLD listening or the procedures of <xref
              target="RFC9251"/>) target="RFC9251" format="default"/>) that a tenant system reachable via one
              of its local ACs to BD&nbhy;R BD-R is interested in (S,G) traffic.
              The DF is responsible for originating an SBD-SMET route for
              (S,G), following normal OISM procedures.  If the DF is a MEG,
              it MUST <bcp14>MUST</bcp14> originate the corresponding MVPN C&nbhy;multicast C-multicast
              Source Tree Join(S,G) route; if the DF is not a MEG, the MEG
              SBD&nbhy;DR
              SBD-DR SBD MUST <bcp14>MUST</bcp14> originate the C&nbhy;multicast C-multicast route when
              it receives the SMET route.
              <vspace/>
              <vspace/>
                  </t>
                  <t>
              Optionally, if the non-DF is a MEG, it MAY <bcp14>MAY</bcp14> originate the
              corresponding MVPN C&nbhy;multicast C-multicast Source Tree Join(S,G)
              route. This will cause the traffic to flow to both the DF and
              the non-DF, but only the DF will forward the traffic out an
              AC.  This allows for quicker recovery if the DF's local AC to
              R fails.
                  </t>
                </li>
                <li>
                  <t>
              If R is attached to a non&nbhy;OISM non-OISM PE, it will receive the
              traffic via an IPMG, as specified in <xref target="no-OISM"/>.
            </t>
          </list> target="no-OISM" format="default"/>.
                  </t>
                </li>
              </ul>
              <t>
          If an EVPN-attached receiver is interested in (*,G) traffic, and
          if it is possible for there to be sources of (*,G) traffic that
          are attached only to L3VPN nodes, the MEGs will have to know the
          group-to-RP mappings.  That will enable them to originate MVPN
          C&nbhy;multicast
          C-multicast Shared Tree Join(*,G) routes and to send them
          towards
          toward the RP. (Since we are assuming in this section that there
          are no tenant multicast routers attached to the EVPN Tenant
          Domain, the RP must be attached via L3VPN.  Alternatively, the MEG
          itself could be configured to function as an RP for group G.)
              </t>
              <t>
          The layer 2 multicast states are constructed as specified in <xref
          target="l2_state"/>. target="l2_state" format="default"/>.
              </t>
              <t>
          In the layer 3 (*,G) multicast state, the IIF is the appropriate
          MVPN tunnel. A MEG will add its IRB
          interfaces to the (*,G) OIF list its IRB
          interfaces for any BDs containing locally attached receivers.  If
          there are receivers attached to other EVPN PEs, then whenever
          (S,G) traffic from an external source matches a (*,G) state, the
          MEG will create (S,G) state, with the MVPN tunnel as the IIF, the
          OIF list copied from the (*,G) state, and the SBD IRB interface
          added to the OIF list.  (Please see the discussion in <xref
          target="gen_prin"/> target="gen_prin" format="default"/> regarding the inclusion of the SBD IRB
          interface in a (*,G) state; the SBD IRB interface is only used in the
          OIF list only for traffic from external sources.)
              </t>
              <!--  <t> -->
        <!--   Some special care is needed in the creation of the layer 3 (*,G) -->
        <!--   multicast state.  Suppose group G has both external sources -->
        <!--   (sources outside the EVPN Tenant Domain) and internal sources -->
        <!--   (sources inside the EVPN Tenant Domain). <xref target="rpf"/> -->
        <!--   states that when there are internal sources, the SBD IRB interface -->
        <!--   must not be added to the oiflist of the (*,G) state.  Traffic from -->
        <!--   internal sources will have been sent down the SBD IRB interface of -->
        <!--   its ingress PE, and thus will already have been delivered to all -->
        <!--   the EVPN PEs that have interest in it.  However, if the oiflist of -->
        <!--   the PEG DR's (*,G) state does not contain its SBD IRB interface, -->
        <!--   then traffic from external sources will not get delivered to other -->
        <!--   EVPN PEs.  Therefore, when a MEG receives (S,G) traffic from an -->
        <!--   MVPN tunnel, and the traffic corresponds to a layer 3 (*,G) state, -->
        <!--   the MEG MUST <bcp14>MUST</bcp14> create (S,G) state.  The iif will be set to the MVPN -->
        <!--   tunnel the (S,G) traffic is expected to arrive on, and the oiflist -->
        <!--   will contain the SBD IRB interface, as well as the IRB interfaces -->
        <!--   of any other BDs attached to the PEG DR that have locally attached -->
        <!--   receivers with interest in the (S,G) traffic. -->
        <!-- </t> -->
        <t>
          Normal MVPN procedures will then result in the MEG getting the
          (*,G) traffic from all the multicast sources for G that are
          attached via L3VPN.  This traffic arrives on MVPN tunnels.  When
          the MEG removes the traffic from these tunnels, it does the IP
          processing.  If there are any receivers on a given BD, BD&nbhy;R, say BD-R,
          that are attached via local EVPN ACs, the MEG sends the traffic
          down its BD&nbhy;R BD-R IRB interface.  If there are any other EVPN PEs
          that are interested in the (*,G) traffic, the MEG sends the
          traffic down the SBD IRB interface.  Normal OISM procedures then
          distribute the traffic as needed to other EVPN&nbhy;PEs. EVPN-PEs.
              </t>
            </section>
            <!-- mvpn_join -->
    </section>
          <!-- m2e -->

    <section title="EVPN anchor="e2m" numbered="true" toc="default">
            <name>EVPN Sources with MVPN Receivers" anchor="e2m"> Receivers</name>
            <section title="General procedures" anchor="e2m_general"> anchor="e2m_general" numbered="true" toc="default">
              <name>General Procedures</name>
              <t>
          Consider the case where an EVPN tenant system S is sending IP
          multicast traffic to group G, G and there is a receiver R for the
          (S,G) traffic that is attached to the L3VPN, L3VPN but not attached to
          the EVPN Tenant Domain.  (We assume in  (In this document document, we assume that the
          L3VPN/MVPN&nbhy;only
          L3VPN-/MVPN-only nodes will not have any special procedures to
          deal with the case where a source is inside an EVPN domain.)
              </t>
              <t>
          In this case, an L3VPN PE through which R can be reached has to
          send an MVPN C&nbhy;multicast C-multicast Join(S,G) route to one of the MEGs
          that is attached to the EVPN Tenant Domain.  For this to happen,
          the L3VPN PE must have imported a VPN-IP route for S (either a
          host route or a subnet route) from a MEG.
              </t>
              <t>
          If a MEG determines that there is multicast source transmitting on
          one of its ACs, the MEG SHOULD <bcp14>SHOULD</bcp14> originate a VPN&nbhy;IP VPN-IP host route
          for that source.  This determination SHOULD <bcp14>SHOULD</bcp14> be made by examining
          the IP multicast traffic that arrives on the ACs. (It MAY <bcp14>MAY</bcp14> be made
          by provisioning.)  A MEG SHOULD NOT <bcp14>SHOULD NOT</bcp14> export a VPN&nbhy;IP VPN-IP host
          route for any IP address that is not known to be a multicast
          source (unless it has some other reason for exporting such a
          route).  The VPN&nbhy;IP VPN-IP host route for a given multicast source
          MUST
          <bcp14>MUST</bcp14> be withdrawn if the source goes silent for a configurable
          period of time, time or if it can be determined that the source is no
          longer reachable via a local AC.
              </t>
              <t>
          A MEG SHOULD <bcp14>SHOULD</bcp14> also originate a VPN&nbhy;IP VPN-IP subnet route for each of
          the BDs in the Tenant Domain.
              </t>
              <t>
          VPN&nbhy;IP
          VPN-IP routes exported by a MEG must carry any attributes or
          extended communities
          Extended Communities that are required by L3VPN and MVPN.  In
          particular, a VPN&nbhy;IP VPN-IP route exported by a MEG must carry a VRF
          Route Import Extended Community corresponding to the IP&nbhy;VRF IP-VRF
          from which it is imported, imported and a Source AS Extended Community.
              </t>
              <t>
          As a result, if S is attached to a MEG, the L3VPN nodes will
          direct their MVPN C&nbhy;multicast C-multicast Join routes to that MEG.
          Normal MVPN procedures will cause the traffic to be delivered to
          the L3VPN nodes.  The layer 3 multicast state for (S,G) will have
          the MVPN tunnel on its OIF list.  The IIF will be the IRB
          interface leading to the BD containing S.
              </t>
              <t>
          If S is not attached to a MEG, the L3VPN nodes will direct their
          C&nbhy;multicast
          C-multicast Join routes to whichever MEG appears to be on the
          best route to S's subnet.  Upon receiving the C&nbhy;multicast C-multicast
          Join, that MEG will originate an EVPN SMET route for (S,G).  As a
          result, the MEG will receive the (S,G) traffic at layer 2 via the
          OISM procedures.  The (S,G) traffic will be sent up the
          appropriate IRB interface, and the layer 3 MVPN procedures will
          ensure that the traffic is delivered to the L3VPN nodes that have
          requested it.  The layer 3 multicast state for (S,G) will have the
          MVPN tunnel in the OIF list, and the IIF will be one of the
          following:
          <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>
              If S belongs to a BD that is attached to the MEG, the IIF will
              be the IRB interface to that BD; BD.
                  </t>
                </li>
                <li>
                  <t>
              Otherwise
              Otherwise, the IIF will be the SBD IRB interface.
                  </t>
          </list>
        </t>
                </li>
              </ul>
              <t>
          Note that this works even if S is attached to a non&nbhy;OISM non-OISM PE,
          per the procedures of <xref target="no-OISM"/>. target="no-OISM" format="default"/>.
              </t>
            </section>
            <!-- e2m_general -->
      <section title="Any-Source anchor="e2m_asm" numbered="true" toc="default">
              <name>Any-Source Multicast (ASM) Groups" anchor="e2m_asm"> Groups</name>
              <t>
          Suppose the MEG SBD&nbhy;DR SBD-DR learns that one of the PEs in its
          Tenant Domain is interested in (*,G), (*,G) traffic, where G is an
          Any&nbhy;Source
          Any-Source Multicast (ASM) group.  If there are no tenant
          multicast routers, the MEG SBD&nbhy;DR SHOULD SBD-DR <bcp14>SHOULD</bcp14> perform the "First
          Hop Router" (FHR) Router (FHR)" functionality for group G on behalf of the
          Tenant Domain, as described in <xref target="RFC7761"/>. target="RFC7761" format="default"/>.  This
          means that the MEG SBD&nbhy;DR SBD-DR must know the identity of the
          Rendezvous Point (RP) for each group, must send Register messages
          to the Rendezvous Point, RP, etc.
              </t>
              <t>
          If the MEG SBD&nbhy;DR SBD-DR is to be the FHR for the Tenant Domain, it
          must see all the multicast traffic that is sourced from within the
          domain and destined to an ASM group address.  The MEG can ensure
          this by originating an SBD&nbhy;SMET SBD-SMET route for (*,*).
              </t>
              <t>
          (As a possible optimization, an SBD&nbhy;SMET SBD-SMET route for (*, "any
          ASM group") may be defined in a separate document.)
              </t>
              <t>
          In some deployment scenarios, it may be preferred that the MEG
          that receives the (S,G) traffic over an AC be the one providing the
          FHR functionality.  This behavior is OPTIONAL. <bcp14>OPTIONAL</bcp14>.  If this option is
          used, it MUST <bcp14>MUST</bcp14> be ensured that the MEG DR does not provide
          the FHR functionality for (S,G) traffic that is attached to
          another MEG; FHR functionality for (S,G) traffic from a particular
          source S MUST <bcp14>MUST</bcp14> be provided by only a single router.
              </t>
              <t>
          Other deployment scenarios are also possible.  For example, one
          might want to configure the MEGs themselves to be RPs.  In this
          case, the RPs would have to exchange with each other information
          about which sources are active.  The method exchanging such
          information is outside the scope of this document.
              </t>
            </section>
            <!-- e2m_asm -->
      <section title="Source anchor="e2m_multi" numbered="true" toc="default">
        <name>Source on Multihomed Segment" anchor="e2m_multi"> Segment</name>

<!--[rfced] For clarity, may we change "while" to "whereas" here? This would
make it clear that the intended meaning is a contrast rather than "at the
same time".

Original:
   If S is transmitting to two groups, say G1 and G2, it
   is possible that PE1 will receive the (S,G1) traffic from S while PE2
   receives the (S,G2) traffic from S.

Perhaps:
   If S is transmitting to two groups, say G1 and G2, it
   is possible that PE1 will receive the (S,G1) traffic from S, whereas PE2
   will receive the (S,G2) traffic from S.
-->

              <t>
          Suppose S is attached to a segment that is all&nbhy;active
          multi&nbhy;homed all-active
          multihomed to PEl PE1 and PE2.  If S is transmitting to two
          groups, say G1 and G2, it is possible that PE1 will receive the
          (S,G1) traffic from S while PE2 receives the (S,G2) traffic from
          S.
              </t>
              <t>
          This creates an issue for MVPN/EVPN interworking, because there is
          no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE
          for (S,G1) traffic while selecting PE2 as the ingress PE for
          (S,G2) traffic.
              </t>
              <t>
          However, the following procedure ensures that the IP multicast
          traffic will still flow, even if the L3VPN/MVPN nodes picks pick the
          "wrong" EVPN&nbhy;PE EVPN-PE as the Upstream PE for (say) for, e.g., the (S,G1)
          traffic.
              </t>
              <t>
          Suppose S is on an Ethernet segment, belonging to BD1, that is
          multi&nbhy;homed
          multihomed to both PE1 and PE2, where PE1 is a MEG.  And
          suppose that IP multicast traffic from S to G travels over the AC
          that attaches the segment to PE2.  If PE1 receives a
          C&nbhy;multicast
          C-multicast Source Tree Join (S,G) route, it MUST <bcp14>MUST</bcp14> originate
          an
          a SMET route for (S,G).  Normal OISM procedures will then cause
          PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast
          tunnel.  Normal OISM procedures will also cause PE1 to send the
          (S,G) traffic up its BD1 IRB interface.  Normal MVPN procedures
          will then cause PE1 to forward the traffic on an MVPN tunnel.  In
          this case, the routing is not optimal, but the traffic does flow
          correctly.
              </t>
            </section>
            <!-- e2m_multi -->
    </section>
          <!-- e2m -->

  <!-- </section> <!-\- iwork_model -\-> -->

    <section title="Obtaining anchor="optimal" numbered="true" toc="default">
            <name>Obtaining Optimal Routing of Traffic Between between MVPN and EVPN"
             anchor="optimal"> EVPN</name>
            <t>
        The routing of IP multicast traffic between MVPN nodes and EVPN
        nodes will be optimal as long as there is a MEG along the optimal
        route. There are various deployment strategies that can be used to
        obtain optimal routing between MVPN and EVPN.
            </t>
            <t>
        In one such scenario, a Tenant Domain will have a small number of
        strategically placed MEGs.  For example, a Data Center data center may have a
        small number of MEGs that connect it to a wide-area network.  Then  Then,
        the optimal route into or out of the Data Center data center would be through
        the MEGs.
            </t>
            <t>
        In this scenario, the MEGs do not need to originate VPN&nbhy;IP VPN-IP host
        routes for the multicast sources, sources; they only need to originate
        VPN&nbhy;IP
        VPN-IP subnet routes.  The internal structure of the EVPN is
        completely hidden from the MVPN node.  EVPN actions actions, such as MAC
        Mobility and Mass Withdrawal <xref target="RFC7432"/> target="RFC7432" format="default"/>, have zero
        impact on the MVPN control plane.
            </t>
            <t>
        While this deployment scenario provides the most optimal routing and
        has the least impact on the installed based of MVPN nodes, it does
        complicate network planning considerations.
            </t>
            <t>
        Another way of providing routing that is close to optimal is to turn
        each EVPN PE into a MEG.  Then  Then, routing of MVPN-to-EVPN traffic is
        optimal.  However, routing of EVPN-to-MVPN traffic is not guaranteed
        to be optimal when a source host is on a multi&nbhy;homed multihomed Ethernet
        segment (as discussed in <xref target="e2m"/>.) target="e2m" format="default"/>.)
            </t>
            <t>
        The obvious disadvantage of this method is that it requires every
        EVPN PE to be a MEG.
            </t>
            <t>
        The procedures specified in this document allow an operator to add
        MEG functionality to any subset of his EVPN OISM PEs.  This allows
        an operator to make whatever trade-offs deemed appropriate between
        optimal routing and MEG deployment.
            </t>
          </section>
          <!-- optimal -->

    <section title="Selecting anchor="dr_selection" numbered="true" toc="default">
            <name>Selecting the MEG SBD-DR" anchor="dr_selection"> SBD-DR</name>
            <!-- <t> -->
      <!--   Each MEG for a given Tenant Domain MUST <bcp14>MUST</bcp14> be configured with a "MEG -->
      <!--   Ethernet Segment" for that domain.  This is an Ethernet Segment that -->
      <!--   has no ACs.  Conceptually, it represents the set of non-MEG PEs -->
      <!--   contained in the Tenant Domain.  In the control plane, this Ethernet -->
      <!--   Segment is identified by an ESI of Type 0; thus the ESI is an -->
      <!--   arbitrary 9-octet value, managed and configured by the operator. -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   EVPN supports a number of procedures that can be used to select the -->
      <!--   Designated Forwarder (DF) for a particular BD on a particular -->
      <!--   Ethernet segment.  Some of the possible procedures can be found, -->
      <!--   e.g., in <xref target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, and -->
      <!--   <xref target="I-D.ietf-bess-evpn-pref-df"/>.  Whatever procedure is in use in -->
      <!--   a given deployment can be adapted to select a MEG DR for a given BD, -->
      <!--   as follows. -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   Each MEG will originate an Ethernet Segment route for the MEG -->
      <!--   Ethernet Segment.  It MUST <bcp14>MUST</bcp14> carry an ES-Import Route Target whose -->
      <!--   value is set to the high-order 6-octets of the MEG ESI.  Thus only -->
      <!--   MEGs will import the route. -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   Once the set of MEGs is known, it is also possible to determine the -->
      <!--   set of BDs supported by each MEG.  The DF selection procedure can -->
      <!--   then be used to choose a MEG DR for the SBD.  (The conditions under -->
      <!--   which the MEG DR changes depends upon the DF selection algorithm -->
      <!--   that is in use.) -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   These procedures can also be used to select a DR for each BD.  If -->
      <!--   the interworking scenario requires FHR functionality, it is -->
      <!--   generally the DR for a particular BD that is responsible for -->
      <!--   performing that functionality on behalf of the source hosts on that -->
      <!--   BD. -->
      <!-- </t> -->

<!-- IANA flag: MEG flag -->
    <t>
      Every PE that is eligible for selection as the MEG SBD&nbhy;DR SBD-DR
      originates an SBD&nbhy;IMET SBD-IMET route.  As stated in <xref
      target="no-OISM"/>, target="no-OISM" format="default"/>, these SBD&nbhy;IMET SBD-IMET routes carry a Multicast Flags
      EC with the MEG Flag flag set.
            </t>
            <t>
      These SBD&nbhy;IMET SBD-IMET routes SHOULD <bcp14>SHOULD</bcp14> also carry a DF Election EC.  The DF
      Election EC and its use are specified in <xref
      target="RFC8584"/>. target="RFC8584" format="default"/>. When the route is originated, the
      AC&nbhy;DF
      AC-DF bit in the DF Election EC SHOULD <bcp14>SHOULD</bcp14> be set to zero.  This bit
      is not used when selecting a MEG SBD&nbhy;DR, SBD-DR, i.e., it MUST <bcp14>MUST</bcp14> be ignored
      by the receiver of an SBD&nbhy;IMET SBD-IMET route.
            </t>
            <t>
      In the context of a given Tenant Domain, to select the MEG SBD-DR, the
      MEGs of the Tenant Domain perform the following procedure:
      <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>
          From the set of received SBD&nbhy;IMET SBD-IMET routes for the given tenant
          domain, determine the candidate set of PEs that support MEG
          functionality for that domain.
                </t>
              </li>
              <li>
                <t>
          Select a DF Election election algorithm as specified in <xref
          target="RFC8584"/>. target="RFC8584" format="default"/>. Some of the possible algorithms
          can be found, e.g., in <xref target="RFC7432"/>, target="RFC7432" format="default"/>, <xref
          target="RFC8584"/>, target="RFC8584" format="default"/>, and <xref
          target="I-D.ietf-bess-evpn-pref-df"/>. target="I-D.ietf-bess-evpn-pref-df" format="default"/>.
                </t>
              </li>
              <li>
                <t>
          Apply the DF Election Algorithm election algorithm (see <xref
          target="RFC8584"/>) target="RFC8584" format="default"/>) to the candidate set of PEs.
          The "winner" becomes the MEG SBD-DR.
                </t>
      </list>
    </t>
              </li>
            </ul>
            <t>
      Note that if a given PE supports IPMG (<xref target="mvpn"/>) target="mvpn" format="default"/>) or PEG
      (<xref target="pim_iwork"/>) target="pim_iwork" format="default"/>) functionality as well as MEG
      functionality, its SBD&nbhy;IMET SBD-IMET routes carry only one DF Election EC.
            </t>
          </section>
          <!-- dr_selection -->
  </section>
        <!-- mvpn -->

  <section title="Interworking anchor="gtm" numbered="true" toc="default">
          <name>Interworking with 'Global "Global Table Multicast'"
           anchor="gtm"> Multicast"</name>
          <t>
      If multicast service to the outside sources and/or receivers is
      provided via the BGP-based "Global Table Multicast" (GTM) Multicast (GTM)" procedures
      of <xref target="RFC7716"/>, target="RFC7716" format="default"/>, the procedures of <xref target="mvpn"/> target="mvpn" format="default"/>
      can easily be adapted for EVPN/GTM interworking. The way to adapt the
      MVPN procedures to GTM is explained in <xref target="RFC7716"/>. target="RFC7716" format="default"/>.
          </t>
        </section>
        <!-- gtm -->

  <section title="Interworking anchor="pim_iwork" numbered="true" toc="default">
          <name>Interworking with PIM" anchor="pim_iwork"> PIM</name>
          <t>
      As we have been discussing, discussed, there may be receivers in an EVPN tenant
      domain that are interested in multicast flows whose sources are
      outside the EVPN Tenant Domain.  Or there may be receivers outside an
      EVPN Tenant Domain that are interested in multicast flows whose
      sources are inside the Tenant Domain.
          </t>

          <t>
      If the outside sources and/or receivers are part of an MVPN,
      interworking
      see the procedures for interworking that are covered in <xref target="mvpn"/>. target="mvpn" format="default"/>.
          </t>
          <t>
      There are also cases where an external source or receiver are attached
      via IP, IP and the layer 3 multicast routing is done via PIM.  In this
      case, the interworking between the "PIM domain" and the EVPN tenant
      domain is done at L3 Gateways that perform "PIM/EVPN Gateway" (PEG) Gateway (PEG)"
      functionality.  A PEG is very similar to a MEG, except that its layer
      3 multicast routing is done via PIM rather than via BGP.
          </t>
<!-- IANA flag: PEG flag -->
          <t>
      If external sources or receivers for a given group are attached to a
      PEG via a layer 3 interface, that interface should be treated as a VRF
      interface attached to the Tenant Domain's L3VPN VRF.  The layer 3
      multicast routing instance for that Tenant Domain will either run PIM
      on the VRF interface or will listen for IGMP/MLD messages on that
      interface.  If the external receiver is attached elsewhere on an IP
      network, the PE has to enable PIM on its interfaces to the backbone
      network.  In both cases, the PE needs to perform PEG functionality,
      and its IMET routes must carry the Multicast Flags EC with the PEG
      flag set.
          </t>
          <t>
      For each BD on which there is a multicast source or receiver, one of
      the PEGs will becomes become the PEG DR.  DR selection can be done using the
      same procedures specified in <xref target="dr_selection"/>, target="dr_selection" format="default"/>, except
      with "PEG" substituted for "MEG".
          </t>
          <t>
      As long as there are no tenant multicast routers within the EVPN
      Tenant Domain, the PEGs do not need to run PIM on their IRB
      interfaces.
          </t>
          <section title="Source anchor="evpn_source" numbered="true" toc="default">
            <name>Source Inside EVPN Domain" anchor="evpn_source"> Domain</name>
            <t>
        If a PEG receives a PIM Join(S,G) from outside the EVPN tenant
        domain, it may find it necessary to create (S,G) state.  The PE
        needs to determine whether S is within the Tenant Domain.  If S is
        not within the EVPN Tenant Domain, the PE carries out normal layer 3
        multicast routing procedures.  If S is within the EVPN tenant
        domain, the IIF of the (S,G) state is set as follows:
        <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>
            if
            If S is on a BD that is attached to the PE, the IIF is the
            PE's IRB interface to that BD; BD.
                </t>
              </li>
              <li>
                <t>
            if
            If S is not on a BD that is attached to the PE, the IIF is the
            PE's IRB interface to the SBD.
                </t>
        </list>
      </t>
              </li>
            </ul>
            <t>
        When the PE creates such an (S,G) state, it MUST <bcp14>MUST</bcp14> originate (if it
        hasn't already) an SBD&nbhy;SMET SBD-SMET route for (S,G).  This will cause
        it to pull the (S,G) traffic via layer 2.  When the traffic arrives
        over an EVPN tunnel, it gets sent up an IRB interface where the
        layer 3 multicast routing determines the packet's disposition.  The
        SBD&nbhy;SMET
        SBD-SMET route is withdrawn when the (S,G) state no longer
        exists (unless there is some other reason for not withdrawing it).
            </t>
            <t>
        If there are no tenant multicast routers within the EVPN tenant
        domain, there cannot be an RP in the Tenant Domain, so a PEG does
        not have to handle externally arriving PIM Join(*,G) messages.
            </t>
            <!-- <t> -->
      <!--   It is possible that the PEG may later receive PIM Prune(S,G,rpt) -->
      <!-- from the external network.  At that time, it MAY advertise
           (C&nbhy;S,C&nbhy;G) -->
      <!--   an SMET route with the Exclude Group type bit and IGMPv3 bit in the -->
      <!--   Flags field set (see <xref target="RFC9251"/> for details), -->
      <!-- signaling to other EVPN PEs that the particular
           (C&nbhy;S,C&nbhy;G) traffic is -->
      <!--   not needed. -->
      <!-- </t> -->
      <!-- <t> -->
      <!--   <cref source=" ECR"> -->
      <!--     It seems to me that the above paragraph is not needed, because we -->
      <!--     are assuming there is no RP in the Tenant Domain.  So we can't get -->
      <!--     Prune(S,G,rpt).  Am I wrong about that? -->
      <!--   </cref> -->
      <!-- </t> -->
      <t>
        The PEG DR for a particular BD MUST <bcp14>MUST</bcp14> act as the a First Hop Router
        for that BD.  It will examine all (S,G) traffic on the BD, and
        whenever G is an ASM group, the PEG DR will send Register messages
        to the RP for G. This means that the PEG DR will need to pull all
        the (S,G) traffic originating on a given BD, BD by originating an a SMET
        (*,*) route for that BD.  If a PEG DR is the DR for all the BDs, in
        SHOULD it
        <bcp14>SHOULD</bcp14> originate just an SBD&nbhy;SMET SBD-SMET (*,*) route rather than an a
        SMET (*,*) route for each BD.
            </t>
            <t>
        The rules for exporting IP routes to multicast sources are the same
        as those specified for MEGs in <xref target="e2m"/>, target="e2m" format="default"/>, except that the
        exported routes will be IP routes rather than VPN&nbhy;IP VPN-IP routes,
        and it is not necessary to attach the VRF Route Import EC or the
        Source AS EC.
            </t>
            <t>
        When a source is on a multi&nbhy;homed multihomed segment, the same issue
        discussed in <xref target="e2m_multi"/> target="e2m_multi" format="default"/> exists.  Suppose S is on an
        Ethernet segment, belonging to BD1, that is multi&nbhy;homed multihomed to both
        PE1 and PE2, where PE1 is a PEG.  And suppose that IP multicast
        traffic from S to G travels over the AC that attaches the segment to
        PE2.  If PE1 receives an external PIM Join (S,G) route, it MUST <bcp14>MUST</bcp14>
        originate an a SMET route for (S,G).  Normal OISM procedures will
        cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast
        tunnel.  Normal OISM procedures will also cause PE1 to send the
        (S,G) traffic up its BD1 IRB interface.  Normal PIM procedures will
        then cause PE1 to forward the traffic along a PIM tree.  In this
        case, the routing is not optimal, but the traffic does flow
        correctly.
            </t>
          </section>
          <!-- evpn_source -->

    <section title="Source anchor="external_source" numbered="true" toc="default">
            <name>Source Outside EVPN Domain" anchor="external_source"> Domain</name>
            <t>
        By means of normal OISM procedures, a PEG learns whether there are
        receivers in the Tenant Domain that are interested in receiving
        (*,G) or (S,G) traffic.  The PEG must determine whether or not S (or the RP
        for G) is outside the EVPN Tenant Domain.  If so, and if there is a
        receiver on BD1 interested in receiving such traffic, the PEG DR for
        BD1 is responsible for originating a PIM Join(S,G) or Join(*,G)
        control message.
            </t>
            <t>
        An alternative would be to allow any PEG that is directly attached to
        a receiver to originate the PIM Joins.  Then  Then, the PEG DR would only
        have to originate PIM Joins on behalf of receivers that are not
        attached to a PEG. However, if this is done, it is necessary for the
        PEGs to run PIM on all their IRB interfaces, interfaces so that the PIM Assert
        procedures can be used to prevent duplicate delivery to a given BD.
            </t>
            <t>
        The IIF for the layer 3 (S,G) or (*,G) state is determined by normal
        PIM procedures.  If a receiver is on BD1, and the PEG DR is attached
        to BD1, its IRB interface to BD1 is added to the OIF list.  This
        ensures that any receivers locally attached to the PEG DR will
        receive the traffic.  If there are receivers attached to other EVPN
        PEs, then whenever (S,G) traffic from an external source matches a
        (*,G) state, the PEG will create (S,G) state.  The IIF will be set
        to whatever external interface the traffic is expected to arrive on
        (copied from the (*,G) state), the OIF list is copied from the (*,G)
        state, and the SBD IRB interface is added to the OIF list.
            </t>
            <!-- <t> -->
      <!--   However, there is the following problem.  Suppose group G has both -->
      <!--   external sources (sources outside the EVPN Tenant Domain) and -->
      <!--   internal sources (sources inside the EVPN Tenant Domain). <xref -->
      <!--   target="rpf"/> states that when there are internal sources, the SBD -->
      <!--   IRB interface must not be added to the oiflist of the (*,G) state. -->
      <!--   Traffic from internal sources will have been sent down the SBD IRB -->
      <!--   interface of its ingress PE, and thus will already have been -->
      <!--   delivered to all the EVPN PEs that have interest in it.  However, if -->
      <!--   the oiflist of the PEG DR's (*,G) state does not contain its SBD IRB -->
      <!--   interface, then traffic from external sources will not get delivered -->
      <!--   to other EVPN PEs.  Therefore, when the PEG DR receives (S,G) -->
      <!--   traffic corresponding to a layer 3 (*,G) state, the PEG DR MUST -->
      <!--   create (S,G) state.  The iif will be set to whatever external -->
      <!--   interface the (S,G) traffic is expected to arrive on, and the -->
      <!--   oiflist will contain the SBD IRB interface, as well as the IRB -->
      <!--   interfaces of any other BDs attached to the PEG DR that have locally -->
      <!--   attached receivers with interest in the (S,G) traffic. -->
      <!-- </t> -->
    </section>
          <!-- external source -->
  </section>
        <!-- pim_iwork -->

</section>
      <!-- evpn-pe-l3-iwork -->

<section title="Interworking anchor="external_pim_router" numbered="true" toc="default">
        <name>Interworking with PIM via an External PIM Router"
         anchor="external_pim_router"> Router</name>
        <!--t>
    <cref source=" ECR">
      I made some changes to this section (formerly titled "A Variation on
      External Connection"), so I might have introduced some errors.  I
      removed the requirement for the "gateway BD" to be the SBD, as that
      doesn't seem to be necessary, and I'm not sure we want to say that the
      SBD can have ACs.  I removed the mention of Layer 3 multicast states,
      as I think the Layer 3 states are constructed via normal OISM
      procedures.  I removed the mention of AE bundles because that is an
      implementation/deployment issue.  Please correct anything I screwed up
      here.
    </cref>
  </t-->
  <t>
    <xref target="evpn-pe-l3-iwork"/> target="evpn-pe-l3-iwork" format="default"/> describes how to use an OISM PE router
    as the gateway to a non&nbhy;EVPN non-EVPN multicast domain, domain when the EVPN tenant
    domain is not being used as an intermediate transit network for
    multicast.  An alternative approach is to have one or more external PIM
    routers (perhaps operated by a tenant) on one of the BDs of the tenant
    domain.  We will refer to this BD as the "gateway BD".
        </t>
        <t>
    In this model:
    <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>
        The EVPN Tenant Domain is treated as a stub network attached to the
        external PIM routers.
            </t>
          </li>
          <li>
            <t>
        The external PIM routers follow normal PIM procedures, procedures and provide
        the FHR and LHR functionality for the entire Tenant Domain.
            </t>
          </li>
          <li>
            <t>
        The OISM PEs do not run PIM.
            </t>
          </li>
          <li>
            <t>
        There MUST NOT <bcp14>MUST NOT</bcp14> be more than one gateway BD.
            </t>
          </li>
          <li>
            <t>
        If an OISM PE not attached to the gateway BD has interest in a given
        multicast flow, it conveys that interest, following normal OISM
        procedures, by originating an SBD-SMET route for that flow.
            </t>
          </li>
          <li>
            <t>
        If a PE attached to the gateway BD receives an SBD-SMET, it may need
        to generate and transmit a corresponding IGMP/MLD Join on one or
        more of its ACs.  (Procedures for generating an IGMP/MLD Join as a
        result of receiving an a SMET route are given in <xref
        target="RFC9251"/>.) target="RFC9251" format="default"/>.)  The PE MUST <bcp14>MUST</bcp14> know which BD is the Gateway gateway BD
        and MUST NOT <bcp14>MUST NOT</bcp14> transmit an IGMP/MLD Join to any other BDs.
        Furthermore, even if a particular AC is part of that BD, the PE
        SHOULD NOT
        <bcp14>SHOULD NOT</bcp14> transmit an IGMP/MLD Join on that AC unless there is an
        external PIM router attached via that AC.
        <vspace/>
        <vspace/>
            </t>
            <t>
        As a result, IGMP/MLD messages will be received by the external PIM routers
        on the gateway BD, and those external PIM routers will send PIM Join
        messages externally as required. Traffic for the given multicast flow
        will then be received by one of the external PIM routers, and that
        traffic will be forwarded by that router to the gateway BD.
        <vspace/>
        <vspace/>
            </t>
            <t>
        The normal OISM procedures will then cause the given multicast flow
        to be tunneled to any PEs of the EVPN Tenant Domain that have
        interest in the flow.  PEs attached to the gateway BD will see the
        flow as originating from the gateway BD BD, and other PEs will see the flow
        as originating from the SBD.
            </t>
          </li>
          <li>
            <t>
        An OISM PE attached to a gateway BD MUST <bcp14>MUST</bcp14> set its layer 2 multicast
        state to indicate that each AC to the gateway BD has interest in all
        multicast flows.  It MUST <bcp14>MUST</bcp14> also originate an a SMET route for (*,*).
        The procedures for originating SMET routes are discussed in <xref
        target="interest"/>.
        <vspace/>
        <vspace/> target="interest" format="default"/>.
            </t>
            <t>
        This will cause the OISM PEs attached to the gateway BD to receive
        all the IP multicast traffic that is sourced within the EVPN tenant
        domain,
        domain and to transmit that traffic to the gateway BD, where the
        external PIM routers will receive it.  This enables the external PIM
        routers to perform FHR functions on behalf of the entire Tenant
        Domain.  (Of course, if the gateway BD has a multi&nbhy;homed multihomed
        segment, only the PE that is the DF for that segment will transmit
        the multicast traffic to the segment.)
            </t>
    </list>
  </t>
          </li>
        </ul>
      </section>
      <!-- external_pim_router -->
</section>
    <!-- external -->

<section title="Using anchor="pim" numbered="true" toc="default">
      <name>Using an EVPN Tenant Domain as an Intermediate (Transit) Network for Multicast traffic"
         anchor="pim"> Traffic</name>
      <!--t>
    <cref source=" ECR">
      Basically this section says "Use PIM, send PIM messages transparently,
      and use SMET routes to be sure you pull the right traffic to the right
      place if the traffic is originating from the Tenant Domain, or if the
      traffic is being sent through the Tenant Domain by a tenant router."
      One might expect there to be a "use the SMET routes to recreate the
      PIM messages", but that isn't present in this rev.  (There are a few
      comments where we might consider that.)
    </cref>
  </t-->

  <t>
    In this section, we consider the scenario where one or more BDs of an
    EVPN Tenant Domain are being used to carry IP multicast traffic for
    which the source and at least one receiver are not part the tenant
    domain.  That is, one or more BDs of the Tenant Domain are intermediate
    "links" of a larger multicast tree created by PIM.
      </t>
      <t>
    We define a "tenant multicast router" as a multicast router, running
    PIM, that is:
    <list style="format %d."> that:
      </t>
      <ol spacing="normal" type="1"><li>
          <t>
        is attached to one or more BDs of the Tenant Domain, Domain but
          </t>
        </li>
        <li>
          <t>
        is not an EVPN PE router.
          </t>
    </list>
  </t>
        </li>
      </ol>
      <t>
    In order for an EVPN Tenant Domain to be used as a transit network for IP
    multicast, one or more of its BDs must have tenant multicast routers,
    and an OISM PE that attaching attached to such a BD MUST <bcp14>MUST</bcp14> be provisioned to enable
    PIM on its IRB interface to that BD. (This is true even if none of the
    tenant routers is on a segment attached to the PE.)  Further, all the
    OISM PEs (even ones not attached to a BD with tenant multicast routers)
    MUST
    <bcp14>MUST</bcp14> be provisioned to enable PIM on their SBD IRB interfaces.
      </t>
      <t>
    If PIM is enabled on a particular BD, the DR Selection procedure of
    <xref target="dr_selection"/> MUST target="dr_selection" format="default"/> <bcp14>MUST</bcp14> be replaced by the normal PIM DR
    Election procedure of <xref target="RFC7761"/>. target="RFC7761" format="default"/>.  Note that this may
    result in one of the tenant routers being selected as the DR, DR rather
    than one of the OISM PE routers.  In this case, First Hop Router and
    Last Hop Router functionality will not be performed by any of the EVPN
    PEs.
      </t>
      <t>
    A PIM control message on a particular BD is considered to be a
    link&nbhy;local
    link-local multicast message, and message and, as such such, is sent transparently
    from PE to PE via the BUM tunnel for that BD.  This is true whether the
    control message was received from an AC, AC or whether it was received from
    the local layer 3 routing instance via an IRB interface.
      </t>
      <!--t>
    <cref source=" ECR">
      Do we need to consider "PIM Proxy" optimizations here?
    </cref>
  </t-->
  <t>
    A PIM Join/Prune message contains three fields that are relevant to the
    present discussion:
    <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>
        Upstream Neighbor
          </t>
        </li>
        <li>
          <t>
        Group Address (G)
          </t>
        </li>
        <li>
          <t>
        Source Address (S), omitted in the case of (*,G) Join/Prune messages.
      </t>
    </list> messages
          </t>
        </li>
      </ul>
      <t>
    We will generally speak of a PIM Join as a "Join(S,G)" or a "Join(*,G)"
    message,
    message and will use the term "Join(X,G)" to mean "either Join(S,G) either "Join(S,G)" or
    Join(*,G)".
    "Join(*,G)". In the context of a Join(X,G), we will use the term "X" to
    mean "S "S" in the case of (S,G), (S,G) or G's RP "G's RP" in the case of (*,G)". (*,G).
      </t>
      <t>
    Suppose BD1 contains two tenant multicast routers, say C1 and C2.  Suppose
    C1 is on a segment attached to PE1, PE1 and C2 is on a segment attached to
    PE2.  When C1 sends a PIM Join(X,G) to BD1, the Upstream Neighbor field
    might be set to either PE1, PE2, or C2.  C1 chooses the Upstream
    Neighbor based on its unicast routing.  Typically, it will choose as the
    Upstream Neighbor
    the PIM router on BD1 that is "closest" (according to
    the unicast routing) to X. X as the
    Upstream Neighbor.  Note that this will not necessarily be PE1.
    PE1 may not even be visible to the unicast routing algorithm used by the
    tenant routers.  Even if it is, it is unlikely to be the PIM router that
    is closest to X.  So we need to consider the following two cases:
    <list style="format %d. ">
      </t>
      <ol spacing="normal" type="1"><li>
          <t>
        C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream Neighbor.
        <vspace/>
        <vspace/>
          </t>
          <t>
        PE1's PIM routing instance will receive the Join arrive on the BD1 IRB
        interface.  If X is not within the Tenant Domain, PE1 handles the
        Join according to normal PIM procedures.  This will generally result
        in PE1 selecting an Upstream Neighbor and sending it a Join(X,G).
        <vspace/>
        <vspace/>
          </t>

<!--[rfced] May we update "include" to be "send" in the following sentences?

Original:
   The IIF of the layer 3 (X,G) state will be the SBD IRB interface,
   and the OIF list will include the IRB interface to BD1.
   ...
   The IIF of the layer 3 (X,G) state
   will be the IRB interface to X's BD, and the OIF list will
   include the IRB interface to BD1.
   ...
   The IIF of the layer 3 (X,G) state will be the SBD IRB interface, and
   the OIF list will include the IRB interface to BD1.

Perhaps:
   The IIF of the layer 3 (X,G) state will be the SBD IRB interface,
   and the OIF list will send the IRB interface to BD1.
   ...
   The IIF of the layer 3 (X,G) state
   will be the IRB interface to X's BD, and the OIF list will
   send the IRB interface to BD1.
   ...
   The IIF of the layer 3 (X,G) state will be the SBD IRB interface, and
   the OIF list will send the IRB interface to BD1.
-->

          <t>
        If X is within the Tenant Domain, Domain but is attached to some other PE,
        PE1 sends (if it hasn't already) an SBD&nbhy;SMET SBD-SMET route for (X,G).
        The IIF of the layer 3 (X,G) state will be the SBD IRB interface,
        and the OIF list will include the IRB interface to BD1.
        <vspace/>
        <vspace/>
          </t>
          <t>
        The SBD&nbhy;SMET SBD-SMET route will pull the (X,G) traffic to PE1, and the
        (X,G) state will result in the (X,G) traffic being forwarded to C1.
        <vspace/>
        <vspace/>
          </t>
          <t>
        If X is within the Tenant Domain, Domain but is attached to PE1 itself, no
        SBD&nbhy;SMET
        SBD-SMET route is sent.  The IIF of the layer 3 (X,G) state
        will be the IRB interface to X's BD, and the OIF list will include
        the IRB interface to BD1.
          </t>
        </li>
        <li>
          <t>
        C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the
        Upstream Neighbor.
        <vspace/>
        <vspace/>
          </t>
          <t>
        PE1's PIM routing instance will receive the Join arrive on the BD1 IRB
        interface.  If neither X nor Upstream Neighbor is within the tenant
        domain, PE1 handles the Join according to normal PIM procedures.
        This will NOT result in PE1 sending a Join(X,G).
        <vspace/>
        <vspace/>
          </t>
          <t>
        If either X or Upstream Neighbor is within the Tenant Domain, PE1
        sends (if it hasn't already) an SBD&nbhy;SMET SBD-SMET route for (X,G).  The
        IIF of the layer 3 (X,G) state will be the SBD IRB interface, and
        the OIF list will include the IRB interface to BD1.
        <vspace/>
        <vspace/>
          </t>
          <t>
        The SBD&nbhy;SMET SBD-SMET route will pull the (X,G) traffic to PE1, and the
        (X,G) state will result in the (X,G) traffic being forwarded to C1.
          </t>
    </list>
  </t>
        </li>
      </ol>
      <!--t>
    <cref source=" ECR">
      Above (case 1) is where we might consider using the SMET route to as a
      proxy for a PIM message.
    </cref>
  </t>
  <t>
    <cref source=" ECR">
      Here (case 2) if we wanted to use the SMET route to proxy for the PIM
      Join we'd have to block PIM J/P messages from being sent transparently
      from site to site.
    </cref>
  </t-->
  <!-- <t>It is possible that an EVPN broadcast domain is providing -->
  <!--      transit service for a tenant's larger network and there are tenant -->
  <!--      routers attached to the subnet, running routing protocols like PIM. -->
  <!--      In that case, traffic routed by an upstream NVE to the subnet via IRB -->
  <!--      interface may be expected on a downstream tenant router. However, -->
  <!--      since multicast data traffic sent down the IRB interfaces -->
  <!--      is forwarded to local ACs only and not to other EVPN sites according -->
  <!--      to rule XXX -->
  <!--      <!-\- <xref target="blockrule" format="counter"/> in <xref target="solution"/>, additional -\-> -->
  <!--      procedures are needed to handle this situation with tenant routers. -->
  <!--      In particular, NVEs connecting to tenant routers or traffic sources -->
  <!--      need to run PIM on the IRB interface for the transit subnet and -->
  <!--      the SBD. -->
  <!--   </t> -->
  <!--   <t>Consider the following situation: -->
  <!--   <figure> -->
  <!--       <artwork> -->
  <!--    S1                                  S2 -->
  <!--     \ N1                              / N2 -->
  <!--      CE1a                            CE2b -->
  <!--       \ vlan1                       / vlan1 -->
  <!--        NVE1    -\-\-\-\-\-\-\-\-\-\-\-   NVE2  -\-\-\- CE2a -\- receiver -->
  <!--       / N3                                    N4 -->
  <!--    S3 -->
  <!--       </artwork> -->
  <!--   </figure> -->
  <!--   </t> -->
  <!--   <t>CE1a, CE2a/b are three CE routers on vlan1 that is implemented by EVPN. -->
  <!--      The CEs and NVE1/2 run PIM protocol and are PIM neighbors on vlan1. -->
  <!--      CE2a has a receiver on network N4 for multicast traffic from S1/2/3 -->
  <!--      on network N1/2/3 respectively. -->
  <!--   </t> -->
  <!--   <t>CE2a sends PIM joins to CE1a/CE2b/NVE1 on vlan1 for the three sources -->
  <!--      respectively and they all route traffic accordingly onto vlan1. -->
  <!--      Traffic from S1/2 will reach CE2a because NVE1/2 receive the L2 traffic -->
  <!--      on their ACs and forward across the core following EVPN procedures. -->
  <!--      Traffic from S3 is routed into vlan1 by NVE1 via the IRB interface, -->
  <!--      and per rule XXX -->
  <!--      <!-\- <xref target="blockrule" format="counter"/> in <xref target="solution"/> the traffic will not be -\-> -->
  <!--      sent across the core. Thus, according to the procedures specified -->
  <!--      so far, the traffic from S3 will never be received by NVE2 or CE2a. -->
  <!--   </t> -->
  <!--   <t>To solve this problem, NVE2 needs to know that CE2a sent a PIM join -->
  <!--      to another NVE in vlan1 and needs to pull traffic via the SBD, -->
  <!--      where the traffic via IRB is not blocked on the core side. Because PIM -->
  <!--      protocol already requires a router to process join/prune messages that -->
  <!--      it receives on an interface even if it is not the intended RPF neighbor -->
  <!--      (for the purpose of join suppression and prune overriding), NVE2 can -->
  <!--      realize that the upstream router in the join message is another NVE -->
  <!--      vs. a CE router (this only requires the NVEs to keep track if a neighbor -->
  <!--      is an NVE for the subnet). In that case, it treats that join/prune -->
  <!--      as for itself. Correspondingly, its PIM upstream state machine will -->
  <!--      choose one of the NVEs as the RPF neighbor. Between this local NVE and -->
  <!--      the chosen RPF neighbor there could be multiple subnets including the -->
  <!--      SBD but the SBD IRB interface is explicitly chosen as the RPF -->
  <!--      interface. Corresponding join/prune is sent over the SBD IRB -->
  <!--      interface (optionally the the join/prune could be replaced with -->
  <!--      SMET routes) and the upstream NVE will route traffic through the SBD. -->
  <!--      This NVE then route traffic further downstream to CE routers. -->
  <!--   </t> -->
  <!--   <t>Similarly, if an NVE needs to send PIM join/prune messages due to its -->
  <!--      local IGMP/MLD state changes, the RPF interface is always explicitly -->
  <!--      set to the SBD IRB. -->
  <!--   </t> -->
  <!--   <t>Note that, if CE2a chooses NVE1 or NVE2 instead of CE1a -->
  <!--      as its RPF neighbor for S1, then both CE1a and NVE2 will send -->
  <!--      traffic to vlan1 (NVE1 receives join from NVE2 on the SBD and sends -->
  <!--      join to CE1a on vlan1. NVE1 receives traffic from CE1a on vlan1 -->
  <!--      and route to SBD. NVE2 receives traffic on SBD and route to -->
  <!--      local receivers on vlan1). PIM assert procedure kicks in but only -->
  <!--      on NVE2, as CE1a does not receive traffic from NVE2. To address this, -->
  <!--      an NVE must track all the RPF neighbors and not add an IRB interface -->
  <!--      to the OIF list if it received a corresponding PIM join on the IRB, -->
  <!--      in which a tenant router is listed as the upstream neighbor. -->
  <!--      That tenant router will deliver traffic to the subnet, and the traffic -->
  <!--      will be forwarded through the core as it is not routed down the IRB -->
  <!--      but received on an AC. -->
  <!--   </t> -->
  <!--   <t>With PIM-ASM, if the DR on a source subnet is a tenant router, -->
  <!--      it will handle the registering procedures for PIM-ASM. As a result, -->
  <!--      the NVE at same site as the tenant router/DR MUST <bcp14>MUST</bcp14> not handle registering -->
  <!--      procedures as described in <xref target="solution"/>. -->
  <!--   </t> -->
  </section>
    <!-- Tenant Routers -->
<!-- </section> <!-\- Advanced Topics -\-> -->

<section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
    IANA is requested to assign has assigned new flags in the "Multicast Flags Extended
    Community" registry under the "Border Gateway Protocol (BGP) Extended Communities" registry as shown below.
      </t>

    <table align="center">
          <name>Multicast Flags Extended Community Flags" registry.  These flags are:
    <list style="symbols"> Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
              <th align="left" colspan="1" rowspan="1">Change Controller</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">OISM SBD</td>
              <td align="left" colspan="1" rowspan="1">RFC 9625</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">IPMG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9625</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">MEG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9625</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
	      <tr>
              <td align="left" colspan="1" rowspan="1">11</td>
              <td align="left" colspan="1" rowspan="1">PEG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9625</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
              </tr>
	         <tr>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">OISM-supported</td>
              <td align="left" colspan="1" rowspan="1">RFC 9625</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
          </tbody>
        </table>

<!--      <ul spacing="normal">
        <li>
          <t>
        IPMG
          </t>
        </li>
        <li>
          <t>
        MEG
          </t>
        </li>
        <li>
          <t>
        PEG
          </t>
        </li>
        <li>
          <t>
        OISM SBD
          </t>
        </li>
        <li>
          <t>
        OISM-supported
          </t>
    </list>

  </t>
        </li>
      </ul>
-->

      <!-- <t>This document requests the following IANA assignments: -->
  <!--    <list style="symbols"> -->
  <!--       <t>A "Non-OISM" Sub-Type in -->
  <!--          "EVPN Extended Community Sub-Types" registry for the  -->
  <!--          EVPN Non-OISM Extended Community. -->
  <!--       </t> -->
  <!--       <t>An "Optimized Inter-subnet Multicast" bit (OISM) in the -->
  <!--          Multicast Flags extended community defined in -->
  <!--          <xref target="RFC9251"/> -->
  <!--       </t> -->
  <!--    </list> -->
  <!-- </t> -->
</section>
    <!-- iana -->

<section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    This document uses protocols and procedures defined in the normative
    references,
    references and inherits the security considerations of those
    references.
      </t>
      <t>
    This document adds flags or Extended Communities (ECs) to a number of
    BGP routes, routes in order to signal that particular nodes support the OISM,
    IPMG, MEG, and/or PEG functionalities that are defined in this document.
    Incorrect addition, removal, or modification of those flags and/or ECs
    will cause the procedures defined herein to malfunction, in which case
    loss or diversion of data traffic is possible. Implementations should
	provide tools to easily debug configuration mistakes that cause the
	signaling of incorrect information.
      </t>
      <t>
The interworking with non-OISM networks described in sections 5 Sections <xref target="no-OISM" format="counter"/> and 6,
require <xref target="external" format="counter"/>
requires gateway functions in multiple redundant PEs, among which one of
them is elected as Designated Forwarder for a given BD (or SBD). The
election of the MEG or PEG Designated Router, DR, as well as the IPMG
Designated Forwarder Forwarder, makes use of the RFC8584 Designated Forwarder election
procedures.
procedures <xref target="RFC8584"/>. An attacker with access to one of these Gateways may
influence such election and therefore modify the forwarding of multicast traffic
between the OISM network and the external domain. The operator
should be especially careful with the protection of these gateways by making
sure the management interfaces to access the gateways are only allowed to
authorized operators.
      </t>
      <t>
The document also introduces the concept of per-Tenant-Domain dissemination
for the SMET routes, as opposed to per-BD distribution in [RFC9251]. <xref target="RFC9251"/>. That is,
e.g., an
a SMET route triggered by the reception of an IGMP/MLD join Join in BD-1 on PE1, PE1
needs to be distributed and imported by all PEs of the Tenant Domain, even
to those PEs that are not attached to BD-1. This means that an attacker with
access to only one BD in a PE of the Tenant Domain, Domain might force the advertisement of
SMET routes and impact the resources of all the PEs of the Tenant Domain, as
opposed to only the PEs of that particular BD (as in RFC9251). <xref target="RFC9251"/>). The
implementation should provide ways to filter/control the client IGMP/MLD
reports that are received by the attached hosts.
      </t>
    </section>
    <!-- security -->

<section anchor="Acknowledgements" title="Acknowledgements">
  <t>
    The authors thank Vikram Nagarajan and Princy Elizabeth for their work
    on <xref target="external_pim_router"/> and <xref target="SBD-matching"/>.
    The authors also benefited
    tremendously from discussions with Aldrin Isaac on EVPN multicast
    optimizations.
  </t>
</section> <!-- acks -->

</middle>
  <back>
  <references title="Normative References">

      &RFC2119;
    <displayreference target="I-D.ietf-bier-evpn" to="EVPN-BUM"/>
    <displayreference target="I-D.ietf-bess-evpn-pref-df" to="EVPN-DF"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <!-- normative keywords -->
      &RFC3376;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/>
        <!-- IGMP -->
      &RFC3810;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <!-- MLDv2 -->
      &RFC3032;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <!-- MPLS Encaps -->
      &RFC4360;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml"/>
        <!-- BGP ECs -->
      &RFC6625;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6625.xml"/>
        <!-- MVPN Wildcards -->
      &RFC7153;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml"/>
        <!-- BGP ECs -->
      &RFC7432;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <!-- EVPN -->
      &RFC8174;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <!-- normative keywords capitalized -->
      &RFC8584;
      &RFC9135;
      &RFC9136;
      &RFC9251;
      <?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates'?>
      <?rfc include='reference.I-D.ietf-bess-evpn-optimized-ir'?>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9135.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"/>

<!-- [I-D.ietf-bess-evpn-bum-procedure-updates] Published as RFC 9572 on 05/24/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9572.xml"/>

<!-- [I-D.ietf-bess-evpn-optimized-ir] Published as RFC 9574 on 05/24/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9574.xml"/>

      </references>

    <references title="Informative References">

	  &RFC4364;
      <references>
        <name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <!-- L3VPN -->
	  <!-- &RFC5015; --> <!-- BIDIR-PIM -->
          &RFC6513;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/>
        <!-- MVPN -->
          &RFC6514;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>
        <!-- MVPN -->
          &RFC4541;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml"/>
        <!-- snooping -->
          &RFC7606;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <!-- BGP Error Handling -->
          &RFC7716;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7716.xml"/>
        <!-- GTM -->
		  &RFC7761;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
        <!-- PIM-SM -->
          &RFC8296;
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/>
        <!-- BIER encapsulation -->

      <?rfc include='reference.I-D.ietf-bier-evpn'?>
      <?rfc include='reference.I-D.ietf-bess-evpn-pref-df'?>

<!-- [I-D.ietf-bier-evpn] AUTH48 state as of 08/09/24 (RFC-to-be 9624)
     Long way used to update title and fix initials -->
        <reference anchor="I-D.ietf-bier-evpn" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-evpn-14">
	  <front>
	    <title>EVPN Broadcast, Unknown Unicast, and Multicast (BUM) Using Bit Index Explicit Replication (BIER)</title>
	    <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
	      <organization>Juniper Networks</organization>
	    </author>
	    <author initials="T." surname="Przygienda" fullname="Tony Przygienda">
	      <organization>Juniper Networks</organization>
	    </author>
	    <author initials="A." surname="Sajassi" fullname="Ali Sajassi">
	      <organization>Cisco Systems</organization>
	    </author>
	    <author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
	      <organization>Nokia</organization>
	    </author>
	    <date month="June" year="2024"/>
	  </front>
	  <seriesInfo name="Internet-Draft" value="draft-ietf-bier-evpn-14"/>
	</reference>

<!-- [I-D.ietf-bess-evpn-pref-df] In MISSREF*R as of 08/09/24-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-pref-df.xml"/>

      </references>
    </references>
    <section title="Integrated anchor="irb" numbered="true" toc="default">
      <name>Integrated Routing and Bridging" anchor="irb"> Bridging</name>
      <t>
        This Appendix appendix provides a short tutorial on the interaction of
        routing and bridging.  First  First, it shows the traditional model, where
        bridging and routing are performed in separate devices.  Then  Then, it shows
        the model specified in <xref target="RFC9135"/>, target="RFC9135" format="default"/>, where a single device
        contains both routing and bridging functions.  The latter model is
        presupposed in the body of this document.
      </t>
      <t>
        <xref target="conventional_router"/> target="conventional_router" format="default"/> shows a "traditional" router
        that only does routing and has no L2 bridging capabilities.  There
        are two LANs, LANs: LAN1 and LAN2.  LAN1 is realized by switch1, and LAN2 is realized by
        switch2.  The router has an interface, "lan1" "lan1", that attaches to LAN1
        (via switch1) and an interface "lan2" interface, "lan2", that attachs attaches to LAN2 (via
        switch2).  Each intreface interface is configured, as an IP interface, with an
        IP address and a subnet mask.
      </t>
      <figure align="center" anchor="conventional_router" title="Conventional anchor="conventional_router">
        <name>Conventional Router with LAN Interfaces"> Interfaces</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
        +-------+        +--------+        +-------+
        |       |    lan1|        |lan2    |       |
H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3
        |       |        |        |        |       |
H2 -----|       |        |        |        |       |
        +-------+        +--------+        +-------+
    |_________________|              |__________________|
        LAN1                              LAN2
]]></artwork>
      </figure>
      </t>
      <t>
        IP traffic (unicast or multicast) that remains within a single
        subnet never reaches the router.  For instance, if H1 emits an
        Ethernet frame with H2's MAC address in the Ethernet destination
        address Destination
        Address field, the frame will go from H1 to Switch1 to H2, H2 without
        ever reaching the router.  Since the frame is never seen by a
        router, the IP datagram within the frame remains entirely unchanged,
        e.g., its TTL is not decremented.  The Ethernet Source and
        Destination MAC addresses are not changed either.
      </t>
      <t>
        If H1 wants to send a unicast IP datagram to H3, which is on a
        different subnet, H1 has to be configured with the IP address of a
        "default router".  Let's assume that H1 is configured with an IP
        address of Router1 as its default router address.  H1 compares H3's
        IP address with its own IP address and IP subnet mask, mask and
        determines that H3 is on a different subnet.  So the packet has to
        be routed.  H1 uses ARP to map Router1's IP address to a MAC address
        on LAN1.  H1 then encapsulates the datagram in an Ethernet frame,
        using router1's Router1's MAC address as the destination MAC address, and
        sends the frame to Router1.
      </t>
      <t>
        Router1 then receives the frame over its lan1 interface.  Router1
        sees that the frame is addressed to it, so it removes the Ethernet
        encapsulation and processes the IP datagram.  The datagram is not
        addressed to Router1, so it must be forwarded further.

<!--[rfced] Should "IP destination field" be updated to "IP Destination
Address field" per usage throughout the document?

Original:
   Router1 does
   a lookup of the datagram's IP destination field, and determines that
   the destination (H3) can be reached via Router1's lan2 interface.
-->

	Router1 does
        a lookup of the datagram's IP Destination field and determines that
        the destination (H3) can be reached via Router1's lan2 interface.
        Router1 now performs the IP processing of the datagram: it
        decrements the IP TTL, adjusts the IP header checksum (if present),
        may fragment the packet is as necessary, etc.  Then  Then, the datagram (or
        its fragments) are is encapsulated in an Ethernet header, with
        Router1's MAC address on LAN2 as the MAC Source Address, Address and H3's
        MAC address on LAN2 (which Router1 determines via ARP) as the MAC
        Destination Address.  Finally  Finally, the packet is sent on the lan2
        interface.
      </t>
      <t>
        If H1 has an IP multicast datagram to send (i.e., an IP datagram
        whose Destination Address field is an IP Multicast Address), it
        encapsulates it in an Ethernet frame whose MAC Destination Address
        is computed from the IP Destination Address.
      </t>
      <t>
        If H2 is a receiver for that multicast address, H2 will receive a
        copy of the frame, unchanged, from H1.  The MAC Source Address in
        the Ethernet encapsulation does not change, the IP TTL field does
        not get decremented, etc.
      </t>
      <t>
        If H3 is a receiver for that multicast address, the datagram must be
        routed to H3.  In order for this to happen, Router1 must be
        configured as a multicast router, and it must accept traffic sent to
        Ethernet multicast addresses.  Router1 will receive H1's multicast
        frame on its lan1 interface, will remove the Ethernet encapsulation,
        and will determine how to dispatch the IP datagram based on
        Router1's multicast forwarding states.  If Router1 knows that there
        is a receiver for the multicast datagram on LAN2, it makes a copy of
        the datagram, decrements the TTL (and performs any other necessary
        IP processing), and then encapsulates the datagram in the Ethernet frame for
        LAN2.  The MAC Source Address for this frame will be Router1's MAC
        Source Address on LAN2.  The MAC Destination Address is computed
        from the IP Destination Address.  Finally, the frame is sent on
        Router1's LAN2 interface.
      </t>
      <t>
        <xref target="IRB"/> target="IRB" format="default"/> shows an Integrated Router/Bridge integrated router/bridge that supports
        the routing/bridging integration model of <xref target="RFC9135"/>. target="RFC9135" format="default"/>.
      </t>
      <figure align="center" anchor="IRB" title="Integrated Router/Bridge"> anchor="IRB">
        <name>Integrated Router/Bridge</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
         +------------------------------------------+
         |         Integrated Router/Bridge         |

         +-------+        +--------+        +-------+
         |       |    IRB1|   L3   |IRB2    |       |
 H1 -----+  BD1  +--------+Routing +--------+  BD2  +------H3
         |       |        |Instance|        |       |
 H2 -----|       |        |        |        |       |
         +-------+        +--------+        +-------+
    |___________________|            |____________________|
               LAN1                              LAN2
]]>	</artwork>
	]]></artwork>
      </figure>
      </t>
      <t>
        In <xref target="IRB"/>, target="IRB" format="default"/>, a single device consists of one or more "L3
        Routing Instances".  The routing/forwarding tables of a given
        routing instance is known as an IP-VRF <xref target="RFC9135"/>. target="RFC9135" format="default"/>.
        In the context of EVPN, it is convenient to think of each routing
        instance as representing the routing of a particular tenant.  Each
        IP-VRF is attached to one or more interfaces.
      </t>
      <t>
        When several EVPN PEs have a routing instance of the same tenant
        domain, those PEs advertise IP routes to the attached hosts.  This
        is done as specified in <xref target="RFC9135"/>. target="RFC9135" format="default"/>.
      </t>
      <t>
        The integrated router/bridge shown in <xref target="IRB"/> target="IRB" format="default"/> also
        attaches to a number of "Broadcast Domains" (BDs). Domains (BDs)".  Each BD performs
        the functions that are performed by the bridges in <xref
        target="conventional_router"/>. target="conventional_router" format="default"/>.  To the L3 routing instance, each BD
        appears to be a LAN.  The interface attaching a particular BD to a
        particular IP-VRF is known as an "IRB Interface". interface".  From the
        perspective of L3 routing, each BD is a subnet.  Thus  Thus, each IRB
        interface is configured with a MAC address (which is the router's
        MAC address on the corresponding LAN), as well as an IP address and
        subnet mask.
      </t>
      <t>
        The integrated router/bridge shown in <xref target="IRB"/> target="IRB" format="default"/> may have
        multiple ACs to each BD.  These ACs are visible only to the bridging
        function, not to the routing instance.  To the L3 routing instance,
        there is just one "interface" to each BD.
      </t>
      <t>
        If the L3 routing instance represents the IP routing of a particular
        tenant, the BDs attached to that routing instance are BDs belonging
        to that same tenant.
      </t>
      <t>
        Bridging and routing now proceed exactly as in the case of <xref
        target="conventional_router"/>, target="conventional_router" format="default"/>, except that BD1 replaces Switch1,
        BD2 replaces Switch2, interface IRB1 replaces interface lan1, and
        interface IRB2 replaces interface lan2.
      </t>
      <t>
        It is important to understand that an IRB interface connects an L3
        routing instance to a BD, NOT to a "MAC&nbhy;VRF".  (See MAC-VRF (see <xref
        target="RFC7432"/> target="RFC7432" format="default"/> for the definition of "MAC&nbhy;VRF".) "MAC-VRF").  A
        MAC&nbhy;VRF
        MAC-VRF may contain several BDs, as long as no MAC address
        appears in more than one BD.  From the perspective of the L3 routing
        instance, each individual BD is an individual IP subnet; whether or not
        each BD has its own MAC&nbhy;VRF or not MAC-VRF is irrelevant to the L3
        routing instance.
      </t>
      <t>
        <xref target="two_router_irb"/> target="two_router_irb" format="default"/> illustrates IRB when a pair of BDs
        (subnets) are attached to two different PE routers.  In this
        example, each BD has two segments, and one segment of each BD is
        attached to one PE router.
      </t>
      <figure align="center" anchor="two_router_irb"
                    title="Integrated anchor="two_router_irb">
        <name>Integrated Router/Bridges with Distributed Subnet"> Subnet</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
         +------------------------------------------+
         |        Integrated Router/Bridges         |

         +-------+        +--------+        +-------+
         |       |    IRB1|        |IRB2    |       |
 H1 -----+  BD1  +--------+   PE1  +--------+  BD2  +------H3
         |(Seg-1)|        |(L3 Rtg)|        |(Seg-1)|
 H2 -----|       |        |        |        |       |
         +-------+        +--------+        +-------+
    |___________________|     |       |____________________|
               LAN1           |                   LAN2
                              |
                              |
         +-------+        +--------+        +-------+
         |       |    IRB1|        |IRB2    |       |
 H4 -----+  BD1  +--------+   PE2  +--------+  BD2  +------H5
         |(Seg-2)|        |(L3 Rtg)|        |(Seg-2)|
         |       |        |        |        |       |
         +-------+        +--------+        +-------+
         ]]>	</artwork>
         	]]></artwork>
      </figure>
      </t>
      <t>
        If H1 needs to send an IP packet to H4, it determines from its IP
        address and subnet mask that H4 is on the same subnet as H1.
        Although H1 and H4 are not attached to the same PE router, EVPN
        provides Ethernet communication among all hosts that are on the same
        BD. Thus, H1 thus uses ARP to find H4's MAC address, address and sends an
        Ethernet frame with H4's MAC address in the Destination MAC address Address
        field.  The frame is received at PE1, but since the Destination MAC
        address is not PE1's MAC address, PE1 assumes that the frame is to
        remain on BD1.  Therefore  Therefore, the packet inside the frame is NOT
        decapsulated,
        decapsulated and is NOT send sent up the IRB interface to PE1's routing
        instance. Rather, standard EVPN intra&nbhy;subnet intra-subnet procedures (as
        detailed in <xref target="RFC7432"/>) target="RFC7432" format="default"/>) are used to deliver the frame
        to PE2, which then sends it to H4.
      </t>
      <t>
        If H1 needs to send an IP packet to H5, it determines from its IP
        address and subnet mask that H5 is NOT on the same subnet as H1.
        Assuming that H1 has been configured with the IP address of PE1 as
        its default router, H1 sends the packet in an Ethernet frame with
        PE1's MAC address in its Destination MAC Address field.  PE1
        receives the frame, frame and sees that the frame is addressed to it. Thus, PE1
        thus
        sends the frame up its IRB1 interface to the L3 routing
        instance.  Appropriate IP processing is done, e.g., TTL decrement.
        The L3 routing instance determines that the "next hop" for H5 is
        PE2, so the packet is encapsulated (e.g., in MPLS) and sent across
        the backbone to PE2's routing instance.  PE2 will see that the
        packet's destination, H5, is on BD2 segment-2, segment-2 and will send the
        packet down its IRB2 interface.  This causes the IP packet to be
        encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in
        the Source Address field and H5's MAC address in the Destination
        Address field.
      </t>
      <t>
        Note that if H1 has an IP packet to send to H3, the forwarding of
        the packet is handled entirely within PE1.  PE1's routing instance
        sees the packet arrive on its IRB1 interface, interface and then transmits the
        packet by sending it down its IRB2 interface.
      </t>
      <t>
        Often, all the hosts in a particular Tenant Domain will be
        provisioned with the same value of the default router IP address.
        This IP address can be provisioned as an "anycast address" in all the
        EVPN PEs attached to that Tenant Domain.  Thus  Thus, although all hosts
        are provisioned with the same "default router address", the actual
        default router for a given host will be one of the PEs
        attached to the same Ethernet segment as the host.  This
        provisioning method ensures that IP packets from a given host are
        handled by the closest EVPN PE that supports IRB.
      </t>
      <t>
        In the topology of <xref target="two_router_irb"/>, target="two_router_irb" format="default"/>, one could
        imagine that H1 is configured with a default router address that
        belongs to PE2 but not to PE1.  Inter-subnet routing would still
        work, but IP packets from H1 to H3 would then follow the non-optimal
        path H1-->PE1-->PE2-->PE1-->H3. H1--&gt;PE1--&gt;PE2--&gt;PE1--&gt;H3. Sending traffic on this sort of
        path, where it leaves a router and then comes back to the same
        router, is sometimes known as "hairpinning".  Similarly, if PE2
        supports IRB but PE1 dos not, the same non-optimal path from H1 to
        H3 would have to be followed.  To avoid hairpinning, each EVPN PE
        needs to support IRB.
      </t>
      <t>
        It is worth pointing out the way IRB interfaces interact with
        multicast traffic.  Referring again to <xref
        target="two_router_irb"/>, target="two_router_irb" format="default"/>, suppose PE1 and PE2 are functioning as IP
        multicast routers. Also Suppose Also, suppose that H3 transmits a multicast packet, packet
        and both H1 and H4 are interested in receiving that packet.  PE1
        will receive the packet from H3 via its IRB2 interface.  The
        Ethernet encapsulation from BD2 is removed, the IP header processing
        is done, and the packet is then reencapsulated re-encapsulated for BD1, with PE1's
        MAC address in the MAC Source Address field.  Then  Then, the packet is
        sent down the IRB1 interface.  Layer 2 procedures (as defined in
        <xref target="RFC7432"/> target="RFC7432" format="default"/>) would then be used to deliver a copy of the
        packet locally to H1, H1 and remotely to H4.
      </t>
      <t>
        Please be aware that his this document modifies the semantics, described
        in the previous paragraph, of sending/receiving multicast traffic on
        an IRB interface.  This is explained in <xref target="cp_overview"/> target="cp_overview" format="default"/>
        and subsequent sections.
      </t>
    </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
    The authors thank <contact fullname="Vikram Nagarajan"/> and <contact fullname="Princy Elizabeth"/> for their work
    on Sections <xref target="external_pim_router" format="counter"/> and <xref target="SBD-matching" format="counter"/>.
    The authors also benefited
    tremendously from discussions with <contact fullname="Aldrin Isaac"/> on EVPN multicast
    optimizations.
      </t>
    </section>
    <!-- acks -->

<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->

<!--[rfced] Terminology

a) Throughout the text, the following terms appear to be used inconsistently.
Please review and let us know if/how these terms may be made consistent.

  Destination MAC Address field vs. MAC Destination Address field (word order)
  DR Selection vs. DR selection (capitalization)
  L3 Gateway vs. L3 gateway (capitalization)
  Layer 3 vs. layer 3 (capitalization)
    [Note: "Layer 2" and/or "Layer 3" appear as capital in
           RFCs 7432, 8174, 9135 and 9136.]

b) There is mixed usage of the following terms. May we update them to the
form listed on the right?

  EVPN-PE -> EVPN PE
  IP Multicast Tunnels, IP Multicast tunnel -> IP multicast tunnel
  Join(S,G) -> Join (S,G)
  tenant domain -> Tenant Domain
  Tenant Multicast Router -> tenant multicast router

c) There are some terms that appear in quotes inconsistently and without an
apparent pattern of when they should appear in quotes. May we remove the
quotation marks from all these instances except for when they are being
introduced as terms (e.g., 'which we call "non-OISM PE routers"')?
-->

<!-- [rfced] Acronyms

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Auto-Discovery (A-D)
 Bit Index Explicit Replication (BIER)
 Ethernet Segment Identifier (ESI)
 Include/Exclude (IE)
 IP Virtual Routing and Forwarding (IP-VRF)
 Label Switched Path (LSP)
 Media Access Control (MAC)
 Multicast Listener Discovery (MLD)
 Multicast VPN (MVPN)
 Provider Multicast Service Interface (PMSI)
 Selective PMSI (S-MPSI)
 Virtual eXtensible Local Area Network (VXLAN)

b) We notice that some terms are expanded multiple times throughout
the document. Per the RFC Editor Web Portion of the Style Guide
(https://www.rfc-editor.org/styleguide/part2/#ref_repo), once an
abbreviation has been introduced, the abbreviated form should be
used thereafter. Thus, please consider if we may apply this
guidance to the following terms:

 AR
 ASM
 IR
 EVI
 P2MP
 PTA
 RP
 RT
 SBD

c) "OIF" is expanded as "Outgoing Interface". Should "output interfaces"
be updated to "outgoing interfaces" in the following, or is the text ok
as is?

Original:
   Each layer 2 multicast state (S,G) or (*,G) contains a set of "output
   interfaces" (OIF list).

Perhaps:
   Each layer 2 multicast state (S,G) or (*,G) contains a set of outgoing
   interfaces (an OIF list).

d) FYI, per RFC 9574, we have updated instances of "TSes" to be "TSs".
Please let us know of any objections.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

For example, please consider whether the following should be updated.

traditional:
   First it shows the traditional model, where bridging
   and routing are performed in separate devices.
   ...
   Figure 1 shows a "traditional" router that only does routing and has
   no L2 bridging capabilities.

he:
   For instance, if a particular tenant has n BDs among which he wants to
   send IP multicast traffic, he can simply attach a conventional
   multicast router to all n BDs.

his:
   The procedures specified in this document allow an operator to add
   MEG functionality to any subset of his EVPN OISM PEs.
-->
  </back>
</rfc>