EVPN BUM Using BIER
draft-ietf-bier-evpn-14

BIER                                                            Z. Zhang
Internet-Draft                                             A. Przygienda
Intended status: Standards Track                        Juniper Networks
Expires: 5 July 2024                                          A. Sajassi
                                                           Cisco Systems
                                                              J. Rabadan
                                                                   Nokia
                                                          2 January 2024

                          EVPN BUM Using BIER
                        draft-ietf-bier-evpn-14

Abstract

   This document specifies protocols and procedures for forwarding
   broadcast, unknown unicast, and multicast (BUM) traffic of Ethernet
   VPNs (EVPN) using Bit Index Explicit Replication (BIER).

Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 July 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Zhang, et al.              Expires 5 July 2024                  [Page 1]
Internet-Draft                  bier-evpn                   January 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminologies . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use of the PMSI Tunnel Attribute  . . . . . . . . . . . . . .   4
     2.1.  IP-Based Tunnel and BIER PHP  . . . . . . . . . . . . . .   6
     2.2.  Explicit Tracking . . . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Using IMET/SMET routes  . . . . . . . . . . . . . . .   6
       2.2.2.  Using S-PMSI/Leaf A-D Routes  . . . . . . . . . . . .   7
     2.3.  MPLS Label in PTA . . . . . . . . . . . . . . . . . . . .   8
   3.  Multihoming Split Horizon . . . . . . . . . . . . . . . . . .   8
   4.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Encapsulation and Transmission  . . . . . . . . . . . . .   9
       4.1.1.  At a BFIR that is an Ingress PE . . . . . . . . . . .   9
       4.1.2.  At a BFIR that is a P-tunnel Segmentation Point . . .  11
     4.2.  Disposition . . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.1.  At a BFER that is an Egress PE  . . . . . . . . . . .  12
       4.2.2.  At a BFER that is a P-tunnel Segmentation Point . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   [RFC7432] and [RFC8365] specify the protocols and procedures for
   Ethernet VPNs (EVPNs).  For broadcast, unknown unicast and multicast
   (BUM) traffic, provider/underlay tunnels are used to carry the BUM
   traffic.  Several kinds of tunnel technologies can be used as
   specified in [RFC7432] and [RFC8365], and this document specifies the
   protocols and procedures to use Bit Index Explicit Replication (BIER)
   [RFC8279] as provider tunnels for EVPN BUM traffic.

Zhang, et al.              Expires 5 July 2024                  [Page 2]
Internet-Draft                  bier-evpn                   January 2024

   BIER is an architecture that provides optimal multicast forwarding
   through a "multicast domain", without requiring intermediate routers
   to maintain any per-flow state or to engage in an explicit tree-
   building protocol.

   The EVPN BUM procedures specified in [RFC7432] and extended in
   [I-D.ietf-bess-evpn-bum-procedure-updates], [RFC9251], and
   [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with
   Multicast VPN (MVPN) procedures [RFC6514] and an EVPN Broadcast
   Domain corresponds to a VPN in MVPN.  As such, this document is also
   very much aligned with [RFC8556] that specifies MVPN with BIER.  For
   terseness, some background, terms and concepts are not repeated here.
   Additionally, some text is borrowed verbatim from [RFC8556].

1.1.  Terminologies

   *  ES: Ethernet Segment.

   *  ESI: Ethernet Segment Identifier.

   *  BFR: Bit-Forwarding Router.

   *  BFIR: Bit-Forwarding Ingress Router.

   *  BFER: Bit-Forwarding Egress Router.

   *  BFR-Prefix: An IP address that uniquely identifies a BFR and is
      routable in a BIER domain.

   *  C-S: A multicast source address identifying a multicast source
      located at an EVPN customer site.  "C-" stands for "Customer-".

   *  C-G: A multicast group address used by an EVPN customer.

   *  C-flow: A customer multicast flow.  Each C-flow is identified by
      the ordered pair (source address, group address), where each
      address is in the customer's address space.  The identifier of a
      particular C-flow is usually written as (C-S, C-G).  Sets of
      C-flows can be denoted by the use of the "C-*" wildcard (see
      [RFC6625]), e.g., (C-*, C-G).

   *  P-tunnel.  A multicast tunnel through the network of one or more
      service providers used to transport C-flows.  "P-" stands for
      "Provider-".

   *  IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route.
      Carried in BGP Update messages, these routes are used to advertise
      the "default" P-tunnel for a particular broadcast domain.

Zhang, et al.              Expires 5 July 2024                  [Page 3]
Internet-Draft                  bier-evpn                   January 2024

   *  SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route.
      Carried in BGP Update messages, these routes are used to advertise
      the C-flows that the advertising PE is interested in.

   *  PMSI [RFC6513]: Provider Multicast Service Interface - a
      conceptual interface for a PE to send customer multicast traffic
      to all or some PEs in the same VPN.

   *  I-PMSI: Inclusive PMSI - to all PEs in the same VPN.

   *  S-PMSI: Selective PMSI - to some of the PEs in the same VPN.

   *  I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to
      advertise the tunnels that instantiate an I-PMSI.

   *  S-PMSI A-D route: Selective PMSI Auto-Discovery route used to
      advertise that particular C-flows are bound to (i.e., are
      traveling through) particular P-tunnels.

   *  PMSI Tunnel attribute (PTA): A BGP attribute used to identify a
      particular P-tunnel.

   *  VXLAN [RFC7348]: Virtual eXtensible Local Area Network.

   *  NVGRE [RFC7637]: Network Virtualization using Generic Routing
      Encapsulation.

   *  GENEVE [RFC8926]: Generic Network Virtualization Encapsulation.

   *  VNI: VXLAN Network Identifier.

   *  VSID: Virtual Subnet IDentifier.

   *  RSVP-P2MP [RFC4875]: Resource ReserVation Protocol for Point-to-
      Multipoint TE Label Switched Paths.

   *  mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for
      Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
      Paths.

2.  Use of the PMSI Tunnel Attribute

   [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET)
   routes carry a PMSI Tunnel Attribute (PTA) to identify the particular
   P-tunnel to which one or more BUM flows are being assigned, the same
   as specified in [RFC6514] for MVPN.  [RFC8556] specifies the encoding
   of PTA for the use of BIER with MVPN.  Much of that specification is
   reused for the use of BIER with EVPN and much of the text below is

Zhang, et al.              Expires 5 July 2024                  [Page 4]
Internet-Draft                  bier-evpn                   January 2024

   borrowed verbatim from [RFC8556].

   The PMSI Tunnel Attribute (PTA) contains the following fields:

   *  "Tunnel Type".  The same codepoint 0x0B that IANA has assigned for
      BIER for MVPN [RFC8556] is used for EVPN as well.

   *  "Tunnel Identifier".  This field contains three subfields for
      BIER.  The text below is exactly as in [RFC8556].

      1  The first subfield is a single octet, containing the sub-
         domain-id of the sub-domain to which the BFIR will assign the
         packets that it transmits on the PMSI identified by the Network
         Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D,
         or per-region I-PMSI A-D route that contains this PTA.  How
         that sub-domain is chosen is outside the scope of this
         document.

      2  The second subfield is a two-octet field containing the BFR-id,
         in the sub-domain identified in the first subfield, of the
         router that is constructing the PTA.

      3  The third subfield is the BFR-Prefix (see [RFC8279]) of the
         originator of the route that is carrying this PTA.  This will
         either be a /32 IPv4 address or a /128 IPv6 address.  Whether
         the address is IPv4 or IPv6 can be inferred from the total
         length of the PMSI Tunnel attribute.

         The BFR-prefix need not be the same IP address that is carried
         in any other field of the x-PMSI A-D route, even if the BFIR is
         the originating router of the x-PMSI A-D route.

   *  "MPLS label".  For EVPN-MPLS [RFC7432], this field contains an
      upstream-assigned MPLS label.  It is assigned by the BFIR.
      Constraints on how the originating router selects this label are
      discussed in Section 2.3.  For EVPN-VXLAN/NVGRE/GENEVE [RFC8365]
      [RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of
      global significance.

   *  "Flags".  When the tunnel type is BIER, two of the flags in the
      PTA Flags field are meaningful.  Details about the use of these
      flags can be found in Section 2.2.

      -  "Leaf Info Required per Flow (LIR-pF)" [RFC8534]

      -  "Leaf Info Required Bit (LIR)"

Zhang, et al.              Expires 5 July 2024                  [Page 5]
Internet-Draft                  bier-evpn                   January 2024

   Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI
   A-D, or per-region I-PMSI A-D route, the route MUST NOT be
   distributed beyond the boundaries of a BIER domain.  That is, any
   routers that receive the route must be in the same BIER domain as the
   originator of the route.  If the originator is in more than one BIER
   domain, the route must be distributed only within the BIER domain in
   which the BFR-Prefix in the PTA uniquely identifies the originator.
   As with all MVPN routes, the distribution of these routes is
   controlled by the provisioning of Route Targets.

2.1.  IP-Based Tunnel and BIER PHP

   When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP
   header (and UDP header in the case of VXLAN/GENEVE) is not included
   in the BIER payload, except when it is known apriori that BIER
   Penultimate Hop Popping (PHP) [I-D.ietf-bier-php] is used in the BIER
   domain and the encapsulation (after the BIER header is popped)
   between the BIER Penultimate Hop and the egress PE does not have a
   way to indicate the next header is VXLAN/NVGRE/GENEVE.  In that case
   the full VXLAN/NVGRE/GENEVE encapsulation MUST be used.  In the outer
   IP header, a well-known IP multicast address (to be assigned by IANA)
   is used as the destination address and the egress PEs MUST be set up
   to receive and process packets addressed to the address.  The address
   is used for all Broadcast Domains (BDs) and the inner VXLAN/NVGRE/
   GENEVE header will be used to identify BDs.

2.2.  Explicit Tracking

   When using BIER to transport an EVPN BUM data packet through a BIER
   domain, an ingress PE functions as a BFIR (see [RFC8279]).  The BFIR
   must determine the set of BFERs to which the packet needs to be
   delivered.  This can be done in either of two ways in the following
   two sections.

2.2.1.  Using IMET/SMET routes

   Both IMET and SMET routes provide explicit tracking functionality.

   For an inclusive PMSI, the set of BFERs (egress PEs) includes the
   originators of all IMET routes for a broadcast domain.  For a
   selective PMSI, the set of BFERs (egress PEs) includes the
   originators of corresponding SMET routes.

   The SMET routes do not carry a PTA.  When an ingress PE sends traffic
   on a selective tunnel using BIER, it uses the upstream-assigned label
   that is advertised in its IMET route.

Zhang, et al.              Expires 5 July 2024                  [Page 6]
Internet-Draft                  bier-evpn                   January 2024

   Only when selectively forwarding is for all flows and without tunnel
   segmentation, SMET routes are used without the need for S-PMSI A-D
   routes.  Otherwise, the procedures in the following section apply.

2.2.2.  Using S-PMSI/Leaf A-D Routes

   There are two cases where S-PMSI/Leaf A-D routes are used as
   discussed in the following two sections.

2.2.2.1.  Selective Forwarding Only for Some Flows

   With the SMET procedure, a PE advertises an SMET route for each (C-S,
   C-G) or (C-*, C-G) state that it learns on its Attachment Circuits
   (ACs), and each SMET route is tracked by every PE in the same
   broadcast domain.  It may be desired that SMET routes are not used,
   in order to reduce the burden of explicit tracking.

   In this case, most multicast traffic will follow the I-PMSI
   (advertised via IMET route) and only some flows follow S-PMSIs.  To
   achieve that, S-PMSI/Leaf A-D routes can be used, as specified in
   [I-D.ietf-bess-evpn-bum-procedure-updates].

   The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556]
   apply.

2.2.2.2.  Tunnel Segmentation

   Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
   segmentation, which is also specified in
   [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in
   [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with
   SMET routes.  This is only applicable to EVPN-MPLS.

   The rules specified in Section 2.2.1 of [RFC8556] apply.
   Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the
   LIR-pF flag cannot be used with segmentation.

2.2.2.3.  Applicability of Additional MVPN Specifications

   As with the MVPN case, Section "3.  Use of the PMSI Tunnel Attribute
   in Leaf A-D routes" of [RFC8556] apply.

   Notice that, [RFC8556] refers to procedures specified in [RFC6625]
   and [RFC8534].  Those two documents were specified for MVPN but apply
   to IP multicast payload in EVPN as well.

Zhang, et al.              Expires 5 July 2024                  [Page 7]
Internet-Draft                  bier-evpn                   January 2024

2.3.  MPLS Label in PTA

   Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three
   bullets (they do NOT apply to EVPN) in that section:

   *  If the two routes do not have the same Address Family Identifier
      (AFI) value, then their respective PTAs MUST contain different
      MPLS label values.  This ensures that when an egress PE receives a
      data packet with the given label, the egress PE can infer from the
      label whether the payload is an IPv4 packet or an IPv6 packet.

   *  If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])
      functionality, and if the two routes originate from different VRFs
      on this ingress PE, then the respective PTAs of the two routes
      MUST contain different MPLS label values.

   *  If the BFIR is an ingress PE supporting the "Extranet Separation"
      feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if
      one of the routes carries the "Extranet Separation" extended
      community but the other does not, then the respective PTAs of the
      two routes MUST contain different MPLS label values.

3.  Multihoming Split Horizon

   For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
   the ES from which a BUM packet originates.  A PE receiving that
   packet from the core side will not forward it to the same ES.  The
   procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP
   P2MP tunnels, using downstream- and upstream-assigned ESI labels
   respectively.  For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
   bias procedures, with which a PE receiving a BUM packet from the core
   side knows from encapsulation the ingress PE so it does not forward
   the packet to any multihoming ESes that the ingress PE is on.  This
   is because the ingress PE already forwarded the packet to those ESes
   regardless of whether the ingress PE is a Designated Forwarder for
   those ESes.

   With BIER, the local bias procedure still applies for EVPN-
   VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the
   ingress PE.  For EVPN-MPLS, ESI label procedures also still apply
   though two upstream-assigned labels will be used (one for identifying
   the broadcast domain and one for identifying the ES) - the same as in
   the case of using a single P2MP tunnel for multiple broadcast
   domains.  The BFIR-id in the BIER header identifies the ingress PE
   that assigned those two labels.

Zhang, et al.              Expires 5 July 2024                  [Page 8]
Internet-Draft                  bier-evpn                   January 2024

4.  Data Plane

   Like MVPN, the EVPN application plays the role of the "multicast flow
   overlay" as described in [RFC8279].

4.1.  Encapsulation and Transmission

   A BFIR could be either an ingress PE or a P-tunnel segmentation
   point.  The procedures are slightly different as described below.

4.1.1.  At a BFIR that is an Ingress PE

   To transmit a BUM data packet, an ingress PE first determines the
   route matched for transmission and routes for tracking leaves
   according to the following rules.

   1.  If selective forwarding is not used, or it is not an IP Multicast
       packet after the Ethernet header, the IMET route originated for
       the BD by the ingress PE is the route matched for transmission.
       Leaf tracking routes are all other received IMET routes for the
       BD.

   2.  Otherwise, if selective forwarding is used for all IP Multicast
       traffic based on SMET routes, the IMET route originated for the
       BD by the ingress PE is the route matched for transmission.
       Received SMET routes for the BD whose source and destination
       address fields match the packet's source and destination IP
       address are leaf tracking routes.

   3.  Otherwise, the route matched for transmission is the S-PMSI A-D
       route originated by the ingress PE for the BD, whose source and
       destination address fields match the packet's source and
       destination IP address and has a PTA specifying a valid tunnel
       type that is not "no tunnel info".  Leaf tracking routes are
       determined as follows:

       1)  If the match for transmission route carries a PTA that has
           the LIR flag set but does not have the LIR-pF flag set, the
           routes matched for tracking are Leaf A-D routes whose "route
           key" field is identical to the NLRI of the S-PMSI A-D route.

       2)  If the match for transmission route carries a PTA that has
           the LIR-pF flag, the leaf tracking routes are Leaf A-D routes
           whose "route key" field is derived from the NLRI of the
           S-PMSI A-D route according to the procedures described in
           Section 5.2 of [RFC8534].

Zhang, et al.              Expires 5 July 2024                  [Page 9]
Internet-Draft                  bier-evpn                   January 2024

       Note that in both cases, SMET routes may be used in lieu of Leaf
       A-D routes, as a PE may omit the Leaf A-D route in response to an
       S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route
       with the corresponding Tag, Source, and Group fields is already
       originated [I-D.ietf-bess-evpn-bum-procedure-updates].  In
       particular, in the second case above, even though the SMET route
       does not have a PTA attached, it is still considered a Leaf A-D
       route in response to a wildcard S-PMSI A-D route with the LIR-pF
       bit set.

   4.  Otherwise, the route matched for transmission and leaf tracking
       routes are determined as in rule 1.

   If no route is matched for transmission, the packet is not forwarded
   onto a P-tunnel.  If the tunnel that the ingress determines to use
   based on the route matched for transmission (and considering
   interworking with PEs that do not support certain tunnel types per
   procedures in [RFC9251]) requires leaf tracking (e.g.  Ingress
   Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf
   tracking routes, the packet will not be forwarded onto a P-tunnel
   either.

   The following text assumes that BIER is the determined tunnel type.
   The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if
   the following conditions are all met:

   *  The packet is received on a multihomed ES.

   *  It's EVPN-MPLS.

   *  ESI label procedure is used for split-horizon.

   The MPLS label from the PTA of the route matched for transmission is
   then pushed onto the packet's label stack for EVPN-MPLS.  For EVPN-
   VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the
   packet with the VNI/VSID set to the value in the PTA's label field,
   and then an IP/UDP header is prepended if needed (e.g. for PHP
   purpose).

   Then the packet is encapsulated in a BIER header and forwarded,
   according to the procedures of [RFC8279] and [RFC8296].  See
   especially Section 4, "Imposing and Processing the BIER
   Encapsulation", of [RFC8296].  The "Proto" field in the BIER header
   is set to 2 in the case of EVPN-MPLS, or a value to be assigned in
   the case of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when an IP header is
   not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE.

Zhang, et al.              Expires 5 July 2024                 [Page 10]
Internet-Draft                  bier-evpn                   January 2024

   To create the proper BIER header for a given packet, the BFIR must
   know all the BFERs that need to receive that packet.  This is
   determined from the set of leaf tracking routes.

4.1.2.  At a BFIR that is a P-tunnel Segmentation Point

   In this case, the encapsulation for the upstream segment of the
   P-tunnel includes (among other things) a label that identifies the
   x-PMSI or IMET A-D route that is the match for reception on the
   upstream segment.  The segmentation point re-advertised the route
   into one or more downstream regions.  Each instance of the re-
   advertised route for a downstream region has a PTA that specifies the
   tunnel for that region.  For any particular downstream region, the
   route matched for transmission is the re-advertised route and the
   leaf tracking routes are determined as follows if needed for the
   tunnel type:

   *  If the route matched for transmission is an x-PMSI route, it must
      have the LIR flag set in its PTA and the leaf tracking routes are
      all the matching Leaf A-D and SMET routes received in the
      downstream region.

   *  If the route matched for transmission is an IMET route, the leaf
      tracking routes are all the IMET routes for the same BD received
      in the downstream region.

   If the downstream region uses BIER, the packet is forwarded as
   follows: the upstream segmentation's encapsulation is removed and the
   above-mentioned label is swapped to the upstream-assigned label in
   the PTA of the route matched for transmission, and then a BIER header
   is imposed as in Section 4.1.1.

4.2.  Disposition

   The same procedures in section 4.2 of [RFC8556] are followed for
   EVPN-MPLS, except some EVPN specifics discussed in the following two
   sub-sections in this document.

   For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload
   is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
   field in the VXLAN/NVGRE/GENEVE header is used to determine the
   corresponding broadcast domain.

Zhang, et al.              Expires 5 July 2024                 [Page 11]
Internet-Draft                  bier-evpn                   January 2024

4.2.1.  At a BFER that is an Egress PE

   Once the corresponding broadcast domain is determined from the
   upstream-assigned label or VNI/VSID, EVPN forwarding procedures per
   [RFC7432] or [RFC8365] are followed.  In the case of EVPN-MPLS, if
   there is an inner label in the label stack following the BIER header,
   that inner label is considered the upstream-assigned ESI label for
   split horizon purpose.

4.2.2.  At a BFER that is a P-tunnel Segmentation Point

   This is only applicable to EVPN-MPLS.  The same procedures in
   Section 4.2.2 of [RFC8556] are followed, subject to multihoming
   procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates].

5.  IANA Considerations

   This document requests three assignments in "BIER Next Protocol
   Identifiers" registry, with the following three recommended values:

   *  7: Payload is VXLAN encapsulated (no IP/UDP header)

   *  8: Payload is NVGRE encapsulated (no IP header)

   *  9: Payload is GENEVE encapsulated (no IP/UDP header)

   This document requests assignments of an IPv4 and an IPv6 multicast
   address for the case discussed in Section 2.1.  Preferably this is
   assigned from the Local Network Control Block (224.0.0/24) for IPv4
   and Link-Local Scope Multicast Addresses for IPv6.  The description
   is "NVO BUM Traffic".

6.  Security Considerations

   This document is about using BIER as provider tunnels for EVPN.  It
   is very similar to using BIER as MVPN provider tunnel, and does not
   introduce additional security implications beyond what have been
   discussed in EVPN base protocol specification [RFC7432] and MVPN
   using BIER [RFC8556].

7.  Acknowledgements

   The authors thank Eric Rosen for his review and suggestions.
   Additionally, much of the text is borrowed verbatim from [RFC8556].

8.  References

8.1.  Normative References

Zhang, et al.              Expires 5 July 2024                 [Page 12]
Internet-Draft                  bier-evpn                   January 2024

   [I-D.ietf-bess-evpn-bum-procedure-updates]
              Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
              Sajassi, "Updates on EVPN BUM Procedures", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
              procedure-updates-14, 18 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-bum-procedure-updates-14>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
              RFC 6625, DOI 10.17487/RFC6625, May 2012,
              <https://www.rfc-editor.org/info/rfc6625>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7900]  Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
              and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
              RFC 7900, DOI 10.17487/RFC7900, June 2016,
              <https://www.rfc-editor.org/info/rfc7900>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

Zhang, et al.              Expires 5 July 2024                 [Page 13]
Internet-Draft                  bier-evpn                   January 2024

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

   [RFC8534]  Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang,
              "Explicit Tracking with Wildcard Routes in Multicast VPN",
              RFC 8534, DOI 10.17487/RFC8534, February 2019,
              <https://www.rfc-editor.org/info/rfc8534>.

   [RFC8556]  Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
              and A. Dolganow, "Multicast VPN Using Bit Index Explicit
              Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
              2019, <https://www.rfc-editor.org/info/rfc8556>.

   [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
              "Geneve: Generic Network Virtualization Encapsulation",
              RFC 8926, DOI 10.17487/RFC8926, November 2020,
              <https://www.rfc-editor.org/info/rfc8926>.

   [RFC9251]  Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
              and W. Lin, "Internet Group Management Protocol (IGMP) and
              Multicast Listener Discovery (MLD) Proxies for Ethernet
              VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
              <https://www.rfc-editor.org/info/rfc9251>.

8.2.  Informative References

   [I-D.ietf-bier-php]
              Zhang, Z. J., "BIER Penultimate Hop Popping", Work in
              Progress, Internet-Draft, draft-ietf-bier-php-10, 9 March
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              bier-php-10>.

   [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements]
              Zhang, Z. J., Kebler, R., Lin, W., and E. C. Rosen, "MVPN/
              EVPN C-Multicast Routes Enhancements", Work in Progress,
              Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-
              enhancements-03, 1 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
              mvpn-evpn-cmcast-enhancements-03>.

Zhang, et al.              Expires 5 July 2024                 [Page 14]
Internet-Draft                  bier-evpn                   January 2024

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <https://www.rfc-editor.org/info/rfc7637>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

   Antoni Przygienda
   Juniper Networks
   Email: prz@juniper.net

   Ali Sajassi
   Cisco Systems
   Email: sajassi@cisco.com

   Jorge Rabadan
   Nokia
   Email: jorge.rabadan@nokia.com

Zhang, et al.              Expires 5 July 2024                 [Page 15]