BESS

Internet Engineering Task Force (IETF)                          Z. Zhang
Internet-Draft
Request for Comments: 9572                                        W. Lin
Updates: 7432 (if approved)                                           Juniper Networks
Intended status:
Category: Standards Track                                     J. Rabadan
Expires: May 22, 2022
ISSN: 2070-1721                                                    Nokia
                                                                K. Patel
                                                                  Arrcus
                                                              A. Sajassi
                                                           Cisco Systems
                                                       November 18, 2021
                                                                May 2024

     Updates on to EVPN BUM Broadcast, Unknown Unicast, or Multicast (BUM)
                               Procedures
             draft-ietf-bess-evpn-bum-procedure-updates-14

Abstract

   This document specifies updated procedures for handling broadcast,
   unknown unicast, and multicast Broadcast,
   Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPN), (EVPNs),
   including selective multicast, multicast and segmentation of provider tunnel segmentation. tunnels.
   This document updates RFC 7432.

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 an Internet Standards Track document.

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

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 22, 2022.
   https://www.rfc-editor.org/info/rfc9572.

Copyright Notice

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

   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 Simplified Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Simplified Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Tunnel Segmentation . . . . . . . . . . . . . . . . . . .   4
       2.1.1.
     2.1.  Reasons for Tunnel Segmentation . . . . . . . . . . .   5
   3.  Additional Route Types of EVPN NLRI . . . . . . . . . . . . .   6
     3.1.  Per-Region I-PMSI A-D route . . . . . . . . . . . . . . .   7 Route
     3.2.  S-PMSI A-D route  . . . . . . . . . . . . . . . . . . . .   7 Route
     3.3.  Leaf A-D route  . . . . . . . . . . . . . . . . . . . . .   8 Route
   4.  Selective Multicast . . . . . . . . . . . . . . . . . . . . .   8
   5.  Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Differences from Section 7.2.2 of [RFC7117] When RFC 7117 when Applied to EVPN . . . . . . . . . . . . . . . . . . . . . . . . .   9
           EVPNs
     5.2.  I-PMSI Leaf Tracking  . . . . . . . . . . . . . . . . . .  11
     5.3.  Backward Compatibility  . . . . . . . . . . . . . . . . .  11
       5.3.1.  Designated ASBR Election  . . . . . . . . . . . . . .  13
   6.  Inter-Region Segmentation . . . . . . . . . . . . . . . . . .  13
     6.1.  Area/AS vs. Region  . . . . . . . . . . . . . . . . . . .  13
     6.2.  Per-region  Per-Region Aggregation  . . . . . . . . . . . . . . . . .  14
     6.3.  Use of S-NH-EC  . . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . .  16
   7.  Multi-homing  Multihoming Support  . . . . . . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     12.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     12.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Acknowledgements
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Terminology

   It is expected that audience is familiar with MVPN [RFC6513]
   [RFC6514], VPLS Multicast [RFC7117] and EVPN [RFC7432] concepts and
   terminologies.  For convenience, the following terms are briefly
   explained.

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

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

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

   o  I/S-PMSI A-D Route: Auto-Discovery routes used to announce the
      tunnels that instantiate an I/S-PMSI.

   o  Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf
      tracking purpose.  Triggered by I/S-PMSI A-D routes and targeted
      at triggering route's (re-)advertiser.  Its NLRI embeds the entire
      NLRI of the triggering PMSI A-D route.

   o  IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route used
      to announce the tunnels that instantiate an I-PMSI.

   o  SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective
      Multicast Ethernet Tag A-D route.  The EVPN equivalent of MVPN
      Leaf A-D route but unsolicited and untargeted.

   o  PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute
      that may be attached to PMSI/Leaf A-D routes to provide
      information for a PMSI tunnel.

2.  Introduction

   [RFC7117] specifies procedures for Multicast multicast in the Virtual Private
   LAN Service (VPLS Multicast) multicast), using both inclusive tunnels and
   selective tunnels with or without inter-as inter-AS segmentation, similar to
   the Multicast VPN (MVPN) procedures specified in [RFC6513] and
   [RFC6514].  [RFC7524] specifies inter-area tunnel segmentation
   procedures for both VPLS Multicast multicast and MVPN. MVPNs.

   [RFC7432] specifies BGP MPLS-Based MPLS-based Ethernet VPN (EVPN) procedures,
   including those handling broadcast, unknown unicast, and multicast Broadcast, Unknown Unicast, or Multicast
   (BUM) traffic.  A lot of details are referred  [RFC7432] refers to [RFC7117], yet with
   quite some [RFC7117] for details but leaves
   a few feature gaps like related to selective tunnel and tunnel
   segmentation (Section 2.1).

   This document aims at filling the to fill in those gaps - cover by covering the use of
   selective and segmented tunnels in EVPN.  It follows EVPNs.  In the same editorial choice
   as in RFC7432 and way that
   [RFC7432] refers to [RFC7117] for details, this document only
   specifies differences from relevant procedures provided in [RFC7117]
   and [RFC7524], instead of rather than repeating the text. text from those documents.
   Note that these differences are applicable to EVPN only, EVPNs only and are not
   updates to [RFC7117] or [RFC7524].

   MVPN, VPLS VPLS, and EVPN technologies all have the need to discover other PEs Provider
   Edges (PEs) in the same L3/L2 VPN and announce the inclusive tunnels.
   MVPN technology introduced the I-PMSI Inclusive P-Multicast Service
   Interface (I-PMSI) concept and uses I-PMSI A-D route Auto-Discovery (A-D)
   routes for that. that purpose.  EVPN technology uses Inclusive Multicast
   Ethernet Tag Route (IMET) A-D route routes, but VPLS technology just adds an a PMSI
   Tunnel Attribute (PTA) to the an existing VPLS A-D route for that
   purpose.  For selective tunnels, they all do use the same
   term S-PMSI term:
   Selective PMSI (S-PMSI) A-D routes.

   Many places of this

   This document involve often refers to the I-PMSI concept that concept, which is all the same
   for all three technologies.  For consistency and convenience, an
   EVPN's IMET A-D route and a VPLS's VPLS A-D route carrying a PTA for
   BUM traffic purpose purposes may all each be referred to as an I-PMSI A-D routes route,
   depending on the context.

2.1.

1.1.  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.

1.2.  Terminology

   It is assumed that the reader is familiar with concepts and
   terminologies related to MVPN technology [RFC6513] [RFC6514], VPLS
   multicast [RFC7117], and EVPN technology [RFC7432].  For convenience,
   the following terms are briefly explained.

   AS:  Autonomous System

   PMSI [RFC6513]:  P-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.  Enables traffic to be sent to all PEs in
      the same VPN.

   S-PMSI:  Selective PMSI.  Enables traffic to be sent to some of the
      PEs in the same VPN.

   I/S-PMSI A-D Route:  Auto-Discovery route used to announce the
      tunnels that instantiate an I/S-PMSI.

   Leaf Auto-Discovery (A-D) Route [RFC6513]:  For explicit leaf-
      tracking purposes.  Triggered by I/S-PMSI A-D routes and targeted
      at the triggering route's (re-)advertiser.  Its Network Layer
      Reachability Information (NLRI) embeds the entire NLRI of the
      triggering PMSI A-D route.

   IMET A-D Route [RFC7432]:  Inclusive Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D route
      used to announce the tunnels that instantiate an I-PMSI.

   SMET A-D Route [RFC9251]:  Selective Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of an MVPN Leaf A-D route, but
      unsolicited and untargeted.

   PMSI Tunnel Attribute (PTA):  An optional transitive BGP attribute
      that may be attached to PMSI/Leaf A-D routes to provide
      information for a PMSI tunnel.

   IBGP:  Internal BGP (BGP connection between internal peers).

   EBGP:  External BGP (BGP connection between external peers).

   RT:  Route Target.  Controls route importation and propagation.

2.  Tunnel Segmentation

   MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
   referred to as MVPN/EVPN/VPLS provider tunnels in this document for
   simplicity, can be segmented for technical or administrative reasons,
   which are summarized in Section 2.1.1 2.1 of this document.  [RFC6513] and
   [RFC6514] cover MVPN inter-as inter-AS segmentation, [RFC7117] covers VPLS
   multicast inter-as inter-AS segmentation, and [RFC7524] (Seamless (seamless MPLS
   Multicast)
   multicast) covers inter-area segmentation for both MVPN MVPNs and VPLS. VPLSs.

   With tunnel segmentation, different segments of an end-to-end tunnel
   may have different encapsulation overhead. overheads.  However, the largest
   overhead of the tunnel caused by an encapsulation method on a
   particular segment is not different from the case of a non-segmented
   tunnel with that encapsulation method.  This is similar to the case
   of a network with different link types.

   There is a difference between MVPN and VPLS multicast inter-as inter-AS
   segmentation (the VPLS approach is briefly discribed described in Section 5.1).
   For simplicity, EVPN EVPNs will use the same procedures as in MVPN. those for
   MVPNs.  All ASBRs can re-advertise their choice of the best route.
   Each can become the root of its intra-AS segment and inject traffic
   it receives from its upstream, while each downstream PE/ASBR will
   only pick one of the upstream ASBRs as its upstream.  This is also
   the behavior even for VPLS in the case of inter-area segmentation.

   For inter-area segmentation, [RFC7524] requires the use of Inter-area
   P2MP the Inter-
   Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community (S-NH-EC),
   (S-NH-EC) and the setting of "Leaf the Leaf Information Required" L Required (L) flag
   in the PTA in certain situations.  In the EVPN case, the requirements
   around the S-NH-EC and the PTA "L" L flag in the PTA differ from [RFC7524] to
   make the segmentation procedures transparent to ingress and egress
   PEs.

   [RFC7524] assumes that segmentation happens at area borders.
   However, it could be at "regional" borders, where a region could be a
   sub-area, or even an entire AS plus its external links (Section 6.1).
   That 6.1);
   this would allow for more flexible deployment scenarios (e.g. (e.g., for
   single-area provider networks).  This document extends the inter-area
   segmentation concept to inter-region segmentation for EVPN.

2.1.1. EVPNs.

2.1.  Reasons for Tunnel Segmentation

   Tunnel segmentation may be required and/or desired because of for administrative
   and/or technical reasons.

   For example, an MVPN/VPLS/EVPN network may span multiple providers providers, and the
   end-to-end provider tunnels have to be segmented at and stitched by
   the ASBRs.  Different providers may use different tunnel technologies
   (e.g., provider A uses Ingress Replication ingress replication [RFC7988], provider B uses
   RSVP-TE P2MP [RFC4875] while [RFC4875], and provider C uses mLDP Multipoint LDP (mLDP)
   [RFC6388]).  Even if they use the same tunnel technology like RSVP-TE
   P2MP, (e.g., RSVP-
   TE P2MP), it may be impractical to set up the tunnels across provider
   boundaries.

   The same situations may apply between the ASes and/or areas of a
   single provider.  For example, the backbone area may use RSVP-TE P2MP
   tunnels while non-backbone areas may use mLDP tunnels.

   Segmentation can also be used to divide an AS/area into smaller
   regions, so that control plane state and/or forwarding plane state/
   burden can be limited to that of individual regions.  For example,
   instead of Ingress Replicating ingress-replicating to 100 PEs in the entire AS, with
   inter-area segmentation [RFC7524] [RFC7524], a PE only needs to replicate to
   local PEs and ABRs. Area Border Routers (ABRs).  The ABRs will further
   replicate to their downstream PEs and ABRs.  This not only reduces
   the forwarding plane burden, but also reduces the leaf tracking leaf-tracking
   burden in the control plane.

   Smaller regions also have

   In the benefit that, in case of tunnel aggregation, smaller regions provide the
   benefit of making it is easier to find congruence among the segments of
   different constituent (service) tunnels and the resulting aggregation
   (base) tunnel in a region.  This leads to better bandwidth
   efficiency, because the more congruent they are, the fewer leaves of
   the base tunnel need to discard traffic when a service tunnel's
   segment does not need to receive the traffic (yet it is receiving the
   traffic due to aggregation).

   Another advantage of the smaller region is smaller BIER [RFC8279]
   sub-domains. Bit Index Explicit
   Replication (BIER) subdomains [RFC8279].  With BIER, packets carry a
   BitString, in which the bits correspond to edge routers that needs need to
   receive traffic.  Smaller
   sub-domains subdomains means that smaller BitStrings
   can be used without having to send multiple copies of the same
   packet.

3.  Additional Route Types of EVPN NLRI

   [RFC7432] defines the format of EVPN NLRI as the following: follows:

                    +-----------------------------------+
                    |    Route Type (1 octet)           |
                    +-----------------------------------+
                    |     Length (1 octet)              |
                    +-----------------------------------+
                    | Route Type specific (variable)    |
                    +-----------------------------------+

   So far far, eight route types have been defined in [RFC7432],
   [I-D.ietf-bess-evpn-prefix-advertisement], [RFC9136],
   and
   [I-D.ietf-bess-evpn-igmp-mld-proxy]:

         + [RFC9251]:

            +=======+=========================================+
            | Value | Description                             |
            +=======+=========================================+
            | 1 -     | Ethernet Auto-Discovery (A-D) route
         + Auto-discovery                 |
            +-------+-----------------------------------------+
            | 2 -     | MAC/IP Advertisement route
         +                    |
            +-------+-----------------------------------------+
            | 3 -     | Inclusive Multicast Ethernet Tag route
         +        |
            +-------+-----------------------------------------+
            | 4 -     | Ethernet Segment route
         +                        |
            +-------+-----------------------------------------+
            | 5 -     | IP Prefix Route
         +                               |
            +-------+-----------------------------------------+
            | 6 -     | Selective Multicast Ethernet Tag Route
         +  |
            +-------+-----------------------------------------+
            | 7 -     | Multicast Join Membership Report Synch Route
         + |
            +-------+-----------------------------------------+
            | 8 -     | Multicast Leave Synch Route             |
            +-------+-----------------------------------------+

                     Table 1: Pre-existing Route Types

   This document defines three additional route types:

         +

                  +=======+=============================+
                  | Value | Description                 |
                  +=======+=============================+
                  | 9  -     | Per-Region I-PMSI A-D route
         + |
                  +-------+-----------------------------+
                  | 10 -    | S-PMSI A-D route
         +            |
                  +-------+-----------------------------+
                  | 11 -    | Leaf A-D route              |
                  +-------+-----------------------------+

                          Table 2: New Route Types

   The "Route Type specific" field of the type Type 9 and type Type 10 EVPN NLRIs
   starts with a type Type 1 RD, RD (Route Distinguisher), whose Administrator
   sub-field MUST match that of the RD in all current non-Leaf EVPN routes that
   are not Leaf A-D routes (Section 3.3) EVPN 3.3), i.e., non-Leaf A-D routes from
   the same advertising router for a given EVI. EVPN instance (EVI).

3.1.  Per-Region I-PMSI A-D route Route

   The Per-region per-region I-PMSI A-D route has the following format.  Its usage
   is discussed in Section 6.2.

                   +-----------------------------------+
                   |       RD (8 octets)               |
                   +-----------------------------------+
                   |  Ethernet Tag ID (4 octets)       |
                   +-----------------------------------+
                   |  Region ID (8 octets)             |
                   +-----------------------------------+

   The Region ID identifies the region and is encoded just as how in the same way
   that an
   Extended Community EC is encoded, as detailed in Section 6.2.

3.2.  S-PMSI A-D route Route

   The S-PMSI A-D route has the following format:

                   +-----------------------------------+
                   |       RD (8 octets)               |
                   +-----------------------------------+
                   |  Ethernet Tag ID (4 octets)       |
                   +-----------------------------------+
                   | Multicast Source Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Source (Variable) (variable)      |
                   +-----------------------------------+
                   |  Multicast Group Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Group   (Variable) (variable)       |
                   +-----------------------------------+
                   |Originator's Addr Length (1 octet) |
                   +-----------------------------------+
                   |Originator's Addr (4 or 16 octets) |
                   +-----------------------------------+

   Other than the addition of the Ethernet Tag ID and Originator's Addr
   Length,
   Length fields, it is identical to the S-PMSI A-D route as defined in
   [RFC7117].  The procedures specified in [RFC7117] also apply
   (including wildcard functionality), except that the granularity level
   is per Ethernet Tag.

3.3.  Leaf A-D route Route

   The Route Type specific field of a Leaf A-D route consists of the
   following:

                   +-----------------------------------+
                   |      Route Key (variable)         |
                   +-----------------------------------+
                   |Originator's Addr Length (1 octet) |
                   +-----------------------------------+
                   |Originator's Addr (4 or 16 octets) |
                   +-----------------------------------+

   A Leaf A-D route is originated in response to a PMSI route, which
   could be an Inclusive Multicast Tag IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI
   A-D route, or some other types of routes that may be defined in the
   future that triggers trigger Leaf A-D routes.  The Route Key is the NLRI of
   the route for which this Leaf A-D route is generated.

   The general procedures of for Leaf A-D route are routes were first specified in
   [RFC6514] for MVPN. MVPNs.  The principles therein apply to VPLS VPLSs and EVPN EVPNs
   as well.  [RFC7117] has provides details for regarding VPLS Multicast, multicast, and
   this document points out some specifics for EVPN, e.g. EVPNs, e.g., in
   Section 5.

4.  Selective Multicast

   [I-D.ietf-bess-evpn-igmp-mld-proxy]

   [RFC9251] specifies procedures for EVPN selective forwarding of IP
   multicast traffic using SMET routes.  It assumes that selective
   forwarding is always used with IR ingress replication for all flows
   (though the same signaling can also be used for an ingress PE to find out
   learn the set of egress PEs for selective forwarding with BIER).  An NVE  A
   Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD"
   stands for "Multicast Listener Discovery") that it learns on its ACs
   Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that advertises
   are advertised to other NVEs, and a receiving NVE converts the SMET
   routes back to IGMP/MLD messages and sends them out of its ACs.  The
   receiving NVE also uses the SMET routes to identify which NVEs need
   to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve
   selective forwarding using IR ingress replication or BIER.

   With the above procedures, selective forwarding is done for all flows
   flows, and the SMET routes are advertised for all flows.  It is
   possible that an operator may not want to track all those (C-S, C-G)
   or (C-*,C-G) state states on the NVEs, and the multicast traffic pattern
   allows inclusive forwarding for most flows while selective forwarding
   is needed only for a few high-rate flows.  For that, that reason, or for
   tunnel types other than IR/BIER, ingress replication or BIER, S-PMSI/Leaf A-D
   procedures defined for Selective
   Multicast selective multicast for VPLS in [RFC7117] are
   used.  Other than the fact that different route types and formats are
   specified with an EVPN SAFI for S-PMSI A-D and Leaf A-D routes
   (Section 3), all procedures specified in [RFC7117] with respect to Selective Multicast
   selective multicast apply to EVPN EVPNs as well, including wildcard
   procedures.  In a nutshell, a source NVE advertises S-PMSI A-D routes
   to announce the tunnels used for certain flows, and receiving NVEs
   either join the announced PIM/mLDP tunnel or respond with Leaf A-D
   routes if the Leaf Information Required L flag is set in the S-PMSI A-D route's PTA (so that
   the source NVE can include them as tunnel leaves).

   An optimization to the [RFC7117] procedures provided in [RFC7117] may be
   applied.  Even if a source NVE sets the L flag to request Leaf A-D
   routes, an egress NVE MAY omit the Leaf A-D route if it has already
   advertised a corresponding SMET route, and the source NVE MUST use
   that in lieu of the Leaf A-D route.

   The optional optimizations specified for MVPN MVPNs in [RFC8534] are also
   applicable to EVPN EVPNs when the procedures for S-PMSI/Leaf A-D routes procedures
   are used for EVPN selective multicast forwarding.

5.  Inter-AS Segmentation

5.1.  Differences from Section 7.2.2 of [RFC7117] When RFC 7117 when Applied to EVPN EVPNs

   The first paragraph of Section 7.2.2.2 of [RFC7117] says:

   "...

   |  ... The best route procedures ensure that if multiple ASBRs, in an
   |  AS, receive the same Inter-AS A-D route from their EBGP neighbors,
   |  only one of these ASBRs propagates this route in Internal BGP
   |  (IBGP).  This ASBR becomes the root of the intra-AS segment of the
   |  inter-AS tree and ensures that this is the only ASBR that accepts
   |  traffic into this AS from the inter-AS tree." tree.

   The above VPLS behavior requires complicated VPLS specific VPLS-specific procedures
   for the ASBRs to reach agreement.  For EVPN, EVPNs, a different approach is
   used and
   used; the above quoted text from [RFC7117] is not applicable to EVPN. EVPNs.

   With the different approach for EVPN/MVPN, EVPNs/MVPNs, each ASBR will re-
   advertise its received Inter-AS A-D route to its IBGP peers and
   becomes the root of an intra-AS segment of the inter-AS tree.  The
   intra-AS segment rooted at one ASBR is disjoint with from another intra-AS
   segment rooted at another ASBR.  This is the same as the procedures
   for S-PMSI routes in [RFC7117] itself.

   The following bullet in Section 7.2.2.2 of [RFC7117] does not apply
   to EVPN.

      + EVPNs.

   |  *  If the ASBR uses ingress replication to instantiate the intra-AS intra-
   |     AS segment of the inter-AS tunnel, the re-advertised route MUST
   |     NOT carry the PMSI Tunnel attribute.

   The following bullet in Section 7.2.2.2 of [RFC7117]:

     +

   |  *  If the ASBR uses a P-multicast tree to instantiate the intra-AS
   |     segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
   |     contain the identity of the tree that is used to instantiate
   |     the segment (note that the ASBR could create the identity of
   |     the tree prior to the actual instantiation of the segment).
   |     If, in order to instantiate the segment, the ASBR needs to know
   |     the leaves of the tree, then the ASBR obtains this information
   |     from the A-D routes received from other PEs/ASBRs in the ASBR's
   |     own AS.

   is changed to the following when applied to EVPN:

      "The PMSI Tunnel attribute EVPNs:

   |  *  The PTA MUST specify the tunnel for the segment.  If and only
   |     if, in order to establish the tunnel, the ASBR needs to know
   |     the leaves of the tree, then the ASBR MUST set the L flag to 1
   |     in the PTA to trigger Leaf A-D routes from egress PEs and
   |     downstream ASBRs.  It MUST be (auto-)configured with an import
   |     RT, which controls acceptance of leaf Leaf A-D routes by the ASBR." ASBR.

   Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:

   "If

   |  If the received Inter-AS A-D route carries the PMSI Tunnel
   |  attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
   |  the ASBR that originated the route MUST establish an RSVP-TE P2MP
   |  LSP with the local PE/ASBR as a leaf.  This LSP MAY have been
   |  established before the local PE/ASBR receives the route, or it MAY
   |  be established after the local PE receives the route." route.

   is changed to the following when applied to EVPN:

   "If EVPNs:

   |  If the received Inter-AS A-D route has the L flag set in its PTA,
   |  then a receiving PE MUST originate a corresponding Leaf A-D route,
   while a route.
   |  A receiving ASBR MUST originate a corresponding Leaf A-D route if
   |  and only if one of the following conditions is met: (1) it
   |  received and imported one or more corresponding Leaf A-D routes
   |  from its downstream IBGP or EBGP peers, peers or (2) it has non-null
   |  downstream forwarding state for the PIM/mLDP tunnel that
   |  instantiates its downstream intra-AS segment.  The targeted ASBR
   |  for the Leaf A-D route, which (re-)advertised the Inter-AS A-D
   |  route, MUST establish a tunnel to the leaves discovered by the
   |  Leaf A-D
   routes." routes.

5.2.  I-PMSI Leaf Tracking

   An ingress PE does not set the L flag in its Inclusive Multicast
   Ethernet Tag (IMET) IMET A-D route's PTA,
   even with Ingress Replication tunnels or RSVP-TE P2MP tunnels.  It
   does not rely on the Leaf A-D routes to discover leaves in its AS,
   and Section 11.2 of [RFC7432] explicitly states that the L flag must
   be set to zero. 0.

   An implementation of [RFC7432] might have used the Originating
   Router's IP Address field of the IMET A-D routes to determine the
   leaves,
   leaves or might have used the Next Hop field instead.  Within the
   same AS, both will lead to the same result.

   With segmentation, an ingress PE MUST determine the leaves in its AS
   from the BGP next hops in all its received IMET A-D routes, so it
   does not have to set the L flag set to request Leaf A-D routes.  PEs
   within the same AS will all have different next hops in their IMET
   A-D routes (hence (and hence will all be considered as leaves), and PEs from
   other ASes will have the next hop in their IMET A-D routes set to
   addresses of ASBRs in this local AS, hence AS; hence, only those ASBRs will be
   considered as leaves (as proxies for those PEs in other ASes).  Note
   that in the case of Ingress Replication, ingress replication, when an ASBR re-advertises
   IMET A-D routes to IBGP peers, it MUST advertise the same label for
   all those routes for the same Ethernet Tag ID and the same EVI.
   Otherwise, duplicated copies will be sent by the ingress PE and
   received by egress PEs in other regions.  For the same reason, when
   an ingress PE builds its flooding list, if multiple routes have the
   same (nexthop, label) tuple tuple, they MUST only be added as a single
   branch in the flooding list.

5.3.  Backward Compatibility

   The above procedures assume that all PEs are upgraded to support the
   segmentation procedures:

   o

   *  An ingress PE uses the Next Hop and not the Originating Router's
      IP Address to determine leaves for the I-PMSI tunnel.

   o

   *  An egress PE sends Leaf A-D routes in response to I-PMSI routes,
      if the PTA has the L flag set by the re-advertising ASBR.

   o

   *  In the case of Ingress Replication, ingress replication, when an ingress PE builds its
      flooding list, multiple I-PMSI routes may have the same (nexthop,
      label) tuple tuple, and only a single branch for those routes will be
      added in the flooding list.

   If a deployment has legacy PEs that does do not support the above, then a
   legacy ingress PE would include all PEs (including those in remote
   ASes) as leaves of the inclusive tunnel and try to send traffic to
   them directly (no segmentation), which is either undesired undesirable or not
   possible;
   impossible; a legacy egress PE would not send Leaf A-D routes so the
   ASBRs would not know to send external traffic to them.

   If this backward compatibility backward-compatibility problem needs to be addressed, the
   following procedure MUST be used (see Section 6.2 for per-PE/AS/
   region I-PMSI A-D routes):

   o

   *  An upgraded PE indicates in its per-PE I-PMSI A-D route that it
      supports the new procedures.  This is done by setting a flag bit
      in the EVPN Multicast Flags Extended Community.

   o

   *  All per-PE I-PMSI A-D routes are restricted to the local AS and
      not propagated to external peers.

   o

   *  The ASBRs in an AS originate per-region I-PMSI A-D routes and
      advertise them to their external peers to specify tunnels used to
      carry traffic from the local AS to other ASes.  Depending on the
      types of tunnels being used, the L flag in the PTA may be set, in
      which case the downstream ASBRs and upgraded PEs will send Leaf
      A-D routes to pull traffic from their upstream ASBRs.  In a
      particular downstream AS, one of the ASBRs is elected, based on
      the per-region I-PMSI A-D routes for a particular source AS, to
      send traffic from that source AS to legacy PEs in the downstream
      AS.  The traffic arrives at the elected ASBR on the tunnel
      announced in the best per-region I-PMSI A-D route for the source
      AS, that as selected by the ASBR has selected of from all those the routes that it received
      over EBGP or IBGP sessions.  The election procedure is described
      in Section 5.3.1.

   o

   *  In an ingress/upstream AS, if and only if an ASBR has active
      downstream receivers (PEs and ASBRs), which are learned either
      explicitly via Leaf A-D routes or implicitly via PIM join Join or mLDP
      label mapping, the ASBR originates a per-PE I-PMSI A-D route
      (i.e., a regular Inclusive Multicast Ethernet Tag IMET route) into the local AS, AS and stitches
      incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel.  With this,
      Via this process, it gets traffic from local PEs and send sends the
      traffic to other ASes via the tunnel announced in its per-
      region per-region
      I-PMSI A-D route.

   Note that, that even if there is are no backward compatibility issue, backward-compatibility issues, the use
   of per-region I-PMSI has A-D routes provides the benefit of keeping all
   per-PE I-PMSI A-D routes in their local ASes, greatly reducing the
   flooding of the routes and their corresponding Leaf A-D routes (when needed),
   needed) and reducing the number of inter-as inter-AS tunnels.

5.3.1.  Designated ASBR Election

   When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
   in which a designated ASBR needs to be used to forward traffic to the
   legacy PEs in the AS, it MUST include a DF Designated Forwarder (DF)
   Election EC.  The EC and its use is are specified in [RFC8584].  The AC-DF AC-
   DF bit in the DF Election EC MUST be cleared.  If it is known that no
   legacy PEs exist in the AS, the ASBR MUST NOT include the EC and MUST
   remove the DF Election EC if one is carried in the per-region I-PMSI
   A-D routes that it receives.  Note that this is done for each set of
   per-region I-PMSI A-D routes with the same NLRI.

   Based on the procedures specified in [RFC8584], an election algorithm
   is determined according to the DF Election ECs carried in the set of
   per-region I-PMSI routes of the same NLRI re-adverised re-advertised into the AS.
   The algorithm is then applied to a candidate list, which is the set
   of ASBRs that re-advertised the per-region I-PMSI routes of the same
   NLRI carrying the DF Election EC.

6.  Inter-Region Segmentation

6.1.  Area/AS vs. Region

   [RFC7524] is for addresses MVPN/VPLS inter-area segmentation and does not
   explicitly cover EVPN. EVPNs.  However, if "area" is replaced by "region"
   and "ABR" is replaced by "RBR" (Regional Border Router) Router), then
   everything still works, works and can be applied to EVPN EVPNs as well.

   A region can be a sub-area, or it can be an entire AS AS, including its
   external links.  Instead of automatic automatically defining a region definition based on
   IGP areas, a region would be defined as a BGP peer group.  In fact,
   even with IGP area based a region definition, definition based on an IGP area, a BGP peer group
   listing the PEs and ABRs in an area is still needed.

   Consider the following example diagram for inter-as inter-AS segmentation:

             ---------           ------             ---------
            /         \         /      \           /         \
           /           \       /        \         /           \
          | PE1 o    ASBR1 -- ASBR2    ASBR3 -- ASBR4    o PE2 |
           \           /       \        /         \           /
            \         /         \      /           \         /
             ---------           ------             ---------
             AS 100              AS 200              AS 300
          |-----------|--------|---------|--------|------------|
             segment1  segment2 segment3  segment4  segment5

   The inter-as inter-AS segmentation procedures specified so far ([RFC6513] ([RFC6513],
   [RFC6514], [RFC7117], and Section 5 of this document) require all
   ASBRs to be involved, and Ingress Replication ingress replication is used between two
   ASBRs in different ASes.

   In the above diagram, it's possible that ASBR1/4 does not support
   segmentation, and the provider tunnels in AS 100/300 can actually
   extend across the external link.  In this case, the inter-region
   segmentation procedures can be used instead - -- a region is the entire
   (AS100 +
   AS100 plus the ASBR1-ASBR2 link) link or (AS300 + the entire AS300 plus the
   ASBR3-ASBR4 link). link.  ASBR2/3 would be the RBRs, and ASBR1/4 will just
   be a transit core router with respect to provider tunnels.

   As illustrated in the diagram below, ASBR2/3 will establish a
   multihop EBGP session with session, either with a RR Route Reflector (RR) or directly
   with PEs in the neighboring AS.  I/S-PMSI A-D routes from ingress PEs
   will not be processed by ASBR1/4.  When ASBR2 re-advertises the
   routes into AS 200, it changes the next hop to its own address and
   changes its PTA to specify the tunnel type/identification in its own
   AS.  When ASBR3 re-
   advertises re-advertises I/S-PMSI A-D routes into the
   neighboring AS 300, it changes the next hop to its own address and
   changes its PTA to specify the tunnel type/identification in the
   neighboring region.  Now  Now, the segment is rooted at ASBR3 and extends
   across the external link to PEs.

             ---------           ------             ---------
            /   RR....\.mh-ebpg /      \    mh-ebgp/....RR   \
           /    :      \    `. /        \ .'      /      :    \
          | PE1 o    ASBR1 -- ASBR2    ASBR3 -- ASBR4    o PE2 |
           \           /       \        /         \           /
            \         /         \      /           \         /
             ---------           ------             ---------
             AS 100              AS 200              AS 300
          |-------------------|----------|---------------------|
             segment 1          segment 2         segment 3

6.2.  Per-region  Per-Region Aggregation

   Notice that every I/S-PMSI route from each PE will be propagated
   throughout all the ASes or regions.  They may also trigger
   corresponding Leaf A-D routes routes, depending on the types of tunnels used
   in each region.  This may become result in too many - routes and corresponding
   tunnels.  To address this concern, the I-PMSI routes from all PEs in
   a
   an AS/region can be aggregated into a single I-PMSI route originated
   from the RBRs, and traffic from all those individual I-PMSI tunnels
   will be switched into the single I-PMSI tunnel.  This is like the
   MVPN Inter-AS I-PMSI route originated by ASBRs.

   The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS a "per-AS
   I-PMSI A-D route, route", to be compared against the (per-PE) Intra-AS
   I-PMSI A-D routes originated by each PE.  In this document document, we will
   call it
   as per-region a "per-region I-PMSI A-D route, route" in case cases where we want to
   apply the aggregation at the regional level.  The per-PE I-PMSI routes
   will not be propagated to other regions.  If multiple RBRs are
   connected to a region, then each will advertise such a route, with
   the same Region ID and Ethernet Tag ID (Section 3.1).  Similar to the
   per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each
   select a the best
   one route from all those re-advertised by the upstream RBRs,
   RBRs and hence will only receive traffic injected by one of them.

   MVPN does

   MVPNs do not aggregate S-PMSI routes from all PEs in an AS like it
   does they
   do for I-PMSIs I-PMSI routes, because the number of PEs that will advertise
   S-PMSI routes for the same (s,g) (S,G) or (*,g) (*,G) is small.  This is also the
   case for EVPN, EVPNs, i.e., there is are no per-region S-PMSI routes.

   Notice that per-region I-PMSI routes can also be used to address
   backwards compatibility issue,
   backward-compatibility issues, as discussed in Section 5.3.

   The Region ID in the per-region I-PMSI route's NLRI is encoded like
   an EC.  For example, the Region ID can encode an AS number or area ID
   in the following EC format:

   o

   *  For a two-octet AS number, a Transitive Two-Octet AS-Specific AS-specific EC
      of sub-type 0x09 (Source AS), with the Global Administrator sub-
      field set to the AS number and the Local Administrator sub-field
      set to 0.

   o

   *  For a four-octet AS number, a Transitive Four-Octet AS-Specific AS-specific EC
      of sub-type 0x09 (Source AS), with the Global Administrator sub-
      field set to the AS number and the Local Administrator sub-field
      set to 0.

   o

   *  For an area ID, a Transitive IPv4-Address-Specific IPv4-Address-specific EC of any sub-
      type, with the Global Administrator sub-field set to the area ID
      and the Local Administrator sub-field set to 0.

   Uses

   The use of other EC encoding encodings MAY be allowed as long as it they uniquely
   identifies
   identify the region and the RBRs for the same region uses use the same
   Region ID.

6.3.  Use of S-NH-EC

   [RFC7524] specifies the use of the S-NH-EC because it does not allow
   ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D
   routes to downstream areas.  That behavior is only to be consistent
   with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be
   changed when they're re-advertised by the segmenting ABRs for reasons
   specific to
   MVPN. MVPNs.  For EVPN, EVPNs, it is perfectly fine to change the
   next hop when RBRs re-advertise the I/S-PMSI A-D routes, instead of
   relying on S-
   NH-EC. the S-NH-EC.  As a result, this document specifies that
   RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D
   routes and do not use S-
   NH-EC.  The the S-NH-EC.  This provides the advantage of this is that
   neither ingress PEs nor egress PEs need to understand/use S-NH-EC, the S-NH-
   EC, and a consistent procedure (based on BGP next hop) hops) is used for
   both inter-as inter-AS and inter-region segmentation.

   If a downstream PE/RBR needs to originate Leaf A-D routes, it
   constructs an IP-based Route Target Extended Community by placing the
   IP address carried in the Next Hop of the received I/S-PMSI A-D route
   in the Global Administrator field of the Community, extended community, with the
   Local Administrator field of this Community extended community set to 0 0, and
   also setting the Extended Communities attribute of the Leaf A-D route
   to that
   Community. extended community.

   Similar to [RFC7524], the upstream RBR MUST (auto-)configure a an RT
   with the Global Administrator field set to the Next Hop in the re-
   advertised I/S-PMSI A-D route and with the Local Administrator field
   set to 0.  With this,  Using this technique, the mechanisms specified in
   [RFC4684] for constrained BGP route distribution can be used along
   with this specification to ensure that only the needed PE/ABR will
   have to process a said particular Leaf A-D route.

6.4.  Ingress PE's I-PMSI Leaf Tracking

   [RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an a
   VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA.
   Similar to the inter-as inter-AS case, this is actually not really needed for
   EVPN.
   EVPNs.  To be consistent with the inter-as inter-AS case, the ingress PE does
   not set the L flag in its originated I-PMSI A-D routes, and it
   determines the leaves based on the BGP next hops in its received
   I-PMSI A-D routes, as specified in Section 5.2.

   The same backward compatibility backward-compatibility issue exists, and the same solution
   as in that for the inter-as inter-AS case applies, as specified in Section 5.3.

7.  Multi-homing  Multihoming Support

   To support multi-homing multihoming with segmentation, ESI Ethernet Segment Identifier
   (ESI) labels SHOULD be allocated from a "Domain-wide Common Block"
   (DCB)
   [I-D.ietf-bess-mvpn-evpn-aggregation-label] [RFC9573] for all tunnel types types, including Ingress Replication. Replication
   tunnels [RFC7988].  Via means outside the scope of this document, PEs
   know that ESI labels are from DCB a DCB, and then existing
   multi-homing multihoming
   procedures will then work as is "as is" (whether a multi-homed multihomed Ethernet
   Segment spans across segmentation regions or not).

   Not using DCB-allocated ESI labels is outside the scope of this
   document.

8.  IANA Considerations

   IANA has temporarily assigned the following new EVPN route types in the EVPN "EVPN
   Route Types Types" registry:

   o

            +=======+=============================+===========+
            | Value | Description                 | Reference |
            +=======+=============================+===========+
            | 9 -     | Per-Region I-PMSI A-D route

   o | RFC 9572  |
            +-------+-----------------------------+-----------+
            | 10 -    | S-PMSI A-D route

   o            | RFC 9572  |
            +-------+-----------------------------+-----------+
            | 11 -    | Leaf A-D route

   This document requests              | RFC 9572  |
            +-------+-----------------------------+-----------+

                          Table 3: New Route Types

   IANA to assign has assigned one flag bit from the EVPN
   Multicast "Multicast Flags Extended Community Flags
   Community" registry to be created in
   [draft-ietf-bess-evpn-igmp-mld-proxy]:

   o  Bit-S - by [RFC9251]:

      +=====+======================+===========+===================+
      | Bit | Name                 | Reference | Change Controller |
      +=====+======================+===========+===================+
      | 8   | Segmentation Procedure Support | RFC 9572  | IETF              |
      +-----+----------------------+-----------+-------------------+

                       Table 4: New Multicast Flag

9.  Security Considerations

   The Selective Forwarding procedures specified in this document for selective forwarding
   via S-PMSI/Leaf A-D routes in
   this document are based on the same procedures as those
   used for MVPN MVPNs [RFC6513] [RFC6514] and VPLS Multicast multicast [RFC7117].  The
   procedures for tunnel segmentation
   procedures as specified in this document are
   based on the similar procedures used for MVPN inter-AS tunnel
   segmentation [RFC6514] and inter-area [RFC7524] tunnel segmentation,
   and segmentation [RFC7524],
   as well as procedures for VPLS Multicast [RFC7117] inter-as multicast inter-AS tunnel
   segmentation. segmentation
   [RFC7117].  When applied to EVPN, EVPNs, they do not introduce new security
   concerns besides what have been beyond those discussed in [RFC6513], [RFC6514], [RFC7117],
   and [RFC7524].  They also do not introduce new security concerns
   compared to [RFC7432].

10.  Acknowledgements

   The authors thank Eric Rosen, John Drake, and Ron Bonica for their
   comments and suggestions.

11.  Contributors

   The following also contributed to this document through their earlier
   work in EVPN selective multicast.

   Junlin Zhang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jackey.zhang@huawei.com

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com

12.  References

12.1.

10.1.  Normative References

   [I-D.ietf-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W.
              Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-
              igmp-mld-proxy-14 (work in progress), October 2021.

   [I-D.ietf-bess-mvpn-evpn-aggregation-label]
              Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
              "MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
              ietf-bess-mvpn-evpn-aggregation-label-06 (work in
              progress), April 2021.

   [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>.

   [RFC7117]  Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
              C. Kodeboniya, "Multicast in Virtual Private LAN Service
              (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
              <https://www.rfc-editor.org/info/rfc7117>.

   [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>.

   [RFC7524]  Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
              Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
              Point-to-Multipoint (P2MP) Segmented Label Switched Paths
              (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
              <https://www.rfc-editor.org/info/rfc7524>.

   [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>.

   [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>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

12.2.  Informative References

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W.,

   [RFC9251]  Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J. E., J.,
              and W. Lin, W., "Internet Group Management Protocol (IGMP) and A.
              Sajassi, "IP Prefix Advertisement in
              Multicast Listener Discovery (MLD) Proxies for Ethernet
              VPN (EVPN)",
              draft-ietf-bess-evpn-prefix-advertisement-11 (work in
              progress), RFC 9251, DOI 10.17487/RFC9251, June 2022,
              <https://www.rfc-editor.org/info/rfc9251>.

   [RFC9573]  Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
              "MVPN/EVPN Tunnel Aggregation with Common Labels",
              RFC 9573, DOI 10.17487/RFC9573, May 2018. 2024,
              <https://www.rfc-editor.org/info/rfc9573>.

10.2.  Informative References

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
              November 2006, <https://www.rfc-editor.org/info/rfc4684>.

   [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>.

   [RFC7988]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", RFC 7988,
              DOI 10.17487/RFC7988, October 2016,
              <https://www.rfc-editor.org/info/rfc7988>.

   [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>.

   [RFC9136]  Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
              A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
              (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
              <https://www.rfc-editor.org/info/rfc9136>.

Acknowledgements

   The authors thank Eric Rosen, John Drake, and Ron Bonica for their
   comments and suggestions.

Contributors

   The following people also contributed to this document through their
   earlier work in EVPN selective multicast.

   Junlin Zhang
   Huawei Technologies
   Huawei Bld., No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jackey.zhang@huawei.com

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: lizhenbin@huawei.com

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks

   EMail:
   Email: zzhang@juniper.net

   Wen Lin
   Juniper Networks

   EMail:
   Email: wlin@juniper.net

   Jorge Rabadan
   Nokia

   EMail:
   Email: jorge.rabadan@nokia.com

   Keyur Patel
   Arrcus

   EMail:
   Email: keyur@arrcus.com

   Ali Sajassi
   Cisco Systems

   EMail:
   Email: sajassi@cisco.com