RFC 9572

Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures

📅 published May 2024, from ietf

RFC 9572: Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures ✨

okay bestie, this one is about how BUM traffic (broadcast, unknown unicast, and multicast) gets handled in EVPNs, and it's giving very specific vibes 💅 It's an IETF Standards Track document, published in May 2024, with RFC 9572 as its number. It's an official update to RFC 7432, so it changes what that spec says for EVPNs in a few places 🦋 The ISSN is 2070-1721, and it doesn't list anything it obsoletes.

The squad behind it is Z. Zhang (Juniper Networks), W. Lin (Juniper Networks), J. Rabadan (Nokia), K. Patel (Arrcus), and A. Sajassi (Cisco Systems) 🫶 Literally a dream team.

Abstract 🌸

okay so the abstract says this doc specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs). It covers selective multicast and segmenting provider tunnels too 🔥 And yes, it updates RFC 7432, no cap.

Status of This Memo 📜

this is an Internet Standards Track document 💖 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841.

info about the current status, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9572 🧚

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 🙈 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says.

Table of Contents 🍓

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

1. Introduction 🎀

okay so [RFC7117] lays out how multicast works for VPLS (VPLS multicast). It uses inclusive tunnels and selective tunnels, with or without inter-AS segmentation, kind of like the MVPN procedures in [RFC6513] and [RFC6514]. [RFC7524] adds inter-area tunnel segmentation procedures for both VPLS multicast and MVPNs 💅

[RFC7432] is the BGP MPLS-based Ethernet VPN (EVPN) spec, including how it handles BUM traffic. It points to [RFC7117] for the details, but a few feature gaps around selective tunnels and tunnel segmentation are left open (Section 2.1) 😭

so this doc fills those gaps by covering selective and segmented tunnels in EVPNs ✨ Same energy as RFC 7432 pointing to RFC 7117, this one only lists the differences from the relevant procedures in [RFC7117] and [RFC7524], instead of repeating the whole text. These differences only apply to EVPNs, and they are not updates to [RFC7117] or [RFC7524] 🦋

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

this document often talks about the I-PMSI concept, which works the same for all three technologies. So for consistency and convenience, an EVPN's IMET A-D route and a VPLS A-D route carrying a PTA for BUM traffic can each be called an I-PMSI A-D route, depending on context 🍓

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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 💀

1.2. Terminology 🧚

you're assumed to already know your MVPN stuff [RFC6513] [RFC6514], VPLS multicast [RFC7117], and EVPN [RFC7432]. Just in case, here's a quick rundown 💖

  • AS: Autonomous System
  • PMSI [RFC6513]: P-Multicast Service Interface. A conceptual interface a PE uses to send customer multicast traffic to all or some PEs in the same VPN.
  • I-PMSI: Inclusive PMSI. Lets traffic go to all PEs in the same VPN.
  • S-PMSI: Selective PMSI. Lets traffic go 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]: Used for explicit leaf tracking. It's triggered by I/S-PMSI A-D routes and targeted at the (re-)advertiser of the triggering route. 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. It's the EVPN version 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. It's the EVPN version 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 carry 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 this doc just calls MVPN/EVPN/VPLS provider tunnels for simplicity, can be segmented for technical or administrative reasons. Section 2.1 of this document summarizes those reasons 💅 [RFC6513] and [RFC6514] cover MVPN inter-AS segmentation, [RFC7117] covers VPLS multicast inter-AS segmentation, and [RFC7524] (seamless MPLS multicast) covers inter-area segmentation for both MVPNs and VPLSs.

with tunnel segmentation, different segments of an end-to-end tunnel can have different encapsulation overheads. But the largest overhead a tunnel gets from an encapsulation method on one particular segment is no different from a non-segmented tunnel using that same method. It's kinda like a network with different link types 🌸

there's a difference between MVPN and VPLS multicast inter-AS segmentation (the VPLS approach gets briefly described in Section 5.1). To keep things simple, EVPNs use the same procedures as MVPNs ✨ All ASBRs can re-advertise their choice of best route. Each one can become the root of its intra-AS segment and inject the traffic it receives from its upstream, while each downstream PE/ASBR only picks one of the upstream ASBRs as its upstream. This is also the behavior for VPLS even in the case of inter-area segmentation 🫶

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

[RFC7524] assumes segmentation happens at area borders. It could also happen at "regional" borders, where a region could be a sub-area, or even an entire AS plus its external links (Section 6.1). That allows for more flexible deployment scenarios, like single-area provider networks 🌈 This document extends the inter-area segmentation concept to inter-region segmentation for EVPNs 👑

2.1. Reasons for Tunnel Segmentation ✨

okay bestie, so why would anyone even chop a tunnel into pieces? 🧐 Tunnel segmentation may be required and/or desired for administrative and/or technical reasons 💅

For example, an MVPN/VPLS/EVPN may span multiple 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, and it's giving variety 💀 Provider A uses ingress replication [RFC7988], provider B uses RSVP-TE P2MP [RFC4875], and provider C uses Multipoint LDP (mLDP) [RFC6388]. Even if they all use the same tunnel technology (like 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. Like, instead of ingress-replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524], a PE only needs to replicate to local PEs and 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 burden in the control plane 🫶

In the case of tunnel aggregation, smaller regions provide the benefit of making it 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). Not me getting a bunch of unwanted traffic 😭

Another advantage of the smaller region is smaller Bit Index Explicit Replication (BIER) subdomains [RFC8279] 🧚 With BIER, packets carry a BitString, in which the bits correspond to edge routers that need to receive traffic. Smaller 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 like this 📐

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

So far, eight route types have been defined in [RFC7432], [RFC9136], and [RFC9251] 📋

        +=======+=========================================+
        | Value | Description                             |
        +=======+=========================================+
        | 1     | Ethernet Auto-discovery                 |
        +-------+-----------------------------------------+
        | 2     | MAC/IP Advertisement                    |
        +-------+-----------------------------------------+
        | 3     | Inclusive Multicast Ethernet Tag        |
        +-------+-----------------------------------------+
        | 4     | Ethernet Segment                        |
        +-------+-----------------------------------------+
        | 5     | IP Prefix                               |
        +-------+-----------------------------------------+
        | 6     | Selective Multicast Ethernet Tag Route  |
        +-------+-----------------------------------------+
        | 7     | Multicast 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 9 and Type 10 EVPN NLRIs starts with a Type 1 RD (Route Distinguisher) 🔑 Its Administrator sub-field MUST match that of the RD in all current EVPN routes that are not Leaf A-D routes (Section 3.3), i.e., non-Leaf A-D routes from the same advertising router for a given EVPN instance (EVI). This is the main rule here, so no cap, don't skip it 🚨

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

The 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 in the same way that an EC is encoded, as detailed in Section 6.2 🫧

3.2. S-PMSI A-D 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)      |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group (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 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 🦋

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 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 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 for Leaf A-D routes were first specified in [RFC6514] for MVPNs. The principles therein apply to VPLSs and EVPNs as well. [RFC7117] provides details regarding VPLS multicast, and this document points out some specifics for EVPNs, e.g., in Section 5 💫

4. Selective Multicast 💜

[RFC9251] specifies procedures for EVPN selective forwarding of IP multicast traffic using SMET routes 📡 It assumes that selective forwarding is always used with ingress replication for all flows (though the same signaling can also be used for an ingress PE to learn the set of egress PEs for selective forwarding with BIER). A Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD" stands for "Multicast Listener Discovery") that it learns on its Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that 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 ingress replication or BIER 🌊

With the above procedures, selective forwarding is done for all 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) 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 reason, or for tunnel types other than ingress replication or BIER, S-PMSI/Leaf A-D procedures defined for 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 apply to 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 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 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 MVPNs in [RFC8534] are also applicable to EVPNs when the procedures for S-PMSI/Leaf A-D routes are used for EVPN selective multicast forwarding 🎀

5. Inter-AS Segmentation 🌈

5.1. Differences from Section 7.2.2 of RFC 7117 when Applied to EVPNs 💅

Okay so 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.

That VPLS behavior needs super complicated VPLS-only procedures so the ASBRs can reach agreement 😭. EVPNs do it a totally different way, so the text above from [RFC7117] does not apply to EVPNs. 🙅‍♀️

With the EVPN/MVPN approach, each ASBR re-advertises the Inter-AS A-D route it received to its IBGP peers, and it becomes the root of an intra-AS segment of the inter-AS tree. Each intra-AS segment rooted at one ASBR is disjoint from the intra-AS segments rooted at other ASBRs. This matches the S-PMSI route procedures in [RFC7117] itself, so it's giving consistency 🦋.

The following bullet in Section 7.2.2.2 of [RFC7117] does not apply to EVPNs:

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

This is the bullet in Section 7.2.2.2 of [RFC7117] that gets changed for EVPNs:

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

When applied to EVPNs, it becomes this:

* 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 A-D routes by the ASBR.

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

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.

gets changed for EVPNs like this: ✨

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

5.2. I-PMSI Leaf Tracking 🌸

An ingress PE does not set the L flag in its IMET A-D route's PTA, even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It doesn't rely on Leaf A-D routes to find leaves in its AS, and Section 11.2 of [RFC7432] explicitly says the L flag must be set to 0. Lowkey a clear rule 💖.

An implementation of [RFC7432] might have used the Originating Router's IP Address field of the IMET A-D routes to find the leaves, or it might have used the Next Hop field instead. Inside the same AS, both approaches give the same result.

With segmentation, an ingress PE MUST determine the leaves in its AS from the BGP next hops in all of its received IMET A-D routes, so it doesn't have to set the L flag to request Leaf A-D routes. PEs in the same AS will all have different next hops in their IMET A-D routes (so they'll all count as leaves). PEs from other ASes will have the next hop in their IMET A-D routes set to addresses of ASBRs in this local AS, so only those ASBRs count as leaves, acting as proxies for those PEs in other ASes. 🧚

Also, in the case of ingress replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those routes with the same Ethernet Tag ID and the same EVI. If it doesn't, the ingress PE sends duplicated copies and egress PEs in other regions receive them 🙈. For that same reason, when an ingress PE builds its flooding list and multiple routes have the same (nexthop, label) tuple, they MUST only be added as a single branch in the flooding list. One branch, no drama 💅.

5.3. Backward Compatibility 🎀

The procedures above assume that every PE has been upgraded to support segmentation:

  • An ingress PE uses the Next Hop, not the Originating Router's IP Address, to determine leaves for the I-PMSI tunnel.
  • An egress PE sends Leaf A-D routes in response to I-PMSI routes if the re-advertising ASBR set the L flag in the PTA.
  • With ingress replication, when an ingress PE builds its flooding list, several I-PMSI routes may share the same (nexthop, label) tuple, and only one branch for those routes gets added to the flooding list.

If a deployment still has legacy PEs that don't support the above, a legacy ingress PE would treat all PEs (including the ones in remote ASes) as leaves of the inclusive tunnel and try to send traffic to them directly, with no segmentation. That's either undesirable or impossible 😬. A legacy egress PE wouldn't send Leaf A-D routes, so the ASBRs wouldn't know to send external traffic to it.

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

  • An upgraded PE says in its per-PE I-PMSI A-D route that it supports the new procedures. It does this by setting a flag bit in the EVPN Multicast Flags Extended Community.
  • All per-PE I-PMSI A-D routes are restricted to the local AS and not propagated to external peers.
  • The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise them to their external peers to specify the tunnels used to carry traffic from the local AS to other ASes. Depending on the tunnel types in use, the L flag in the PTA may be set. If it is, 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 gets elected, based on the per-region I-PMSI A-D routes for a particular source AS, to send traffic from that source AS to the 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, as selected by the ASBR from all the routes it received over EBGP or IBGP sessions. The election procedure is described in Section 5.3.1.
  • In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), learned either explicitly via Leaf A-D routes or implicitly via PIM Join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a regular IMET route) into the local AS. It then stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. Through this process it picks up traffic from local PEs and sends that traffic to other ASes via the tunnel announced in its per-region I-PMSI A-D route. 🚀

Even when there are no backward-compatibility issues, per-region I-PMSI A-D routes still help. They keep all per-PE I-PMSI A-D routes in their local ASes, which greatly reduces flooding of those routes and of their corresponding Leaf A-D routes (when needed), and it cuts down the number of 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 where a designated ASBR needs to forward traffic to the legacy PEs in that AS, it MUST include a Designated Forwarder (DF) Election EC. The EC and how it's used are specified in [RFC8584]. The AC-DF bit in the DF Election EC MUST be cleared. If it's known that no legacy PEs exist in the AS, the ASBR MUST NOT include the EC, and it MUST remove the DF Election EC if one is carried in the per-region I-PMSI A-D routes it receives. 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 by the DF Election ECs carried in the set of per-region I-PMSI routes with the same NLRI that were re-advertised into the AS. That algorithm is then applied to a candidate list, which is the set of ASBRs that re-advertised the per-region I-PMSI routes with the same NLRI carrying the DF Election EC. It's giving fair elections, periodt 🗳️💜.

6. Inter-Region Segmentation 🌟

6.1. Area/AS vs. Region ✨

okay so [RFC7524] covers MVPN/VPLS inter-area segmentation but doesn't explicitly talk about EVPNs 🥺. BUT here's the tea: if you swap "area" for "region" and "ABR" for "RBR" (Regional Border Router), everything still works and can totally be applied to EVPNs too 💅✨

A region can be a sub-area, or it can be a whole AS including its external links 🌸. Instead of auto-defining a region from IGP areas, a region gets defined as a BGP peer group 🫶. Even if your region is based on an IGP area, you still need a BGP peer group listing the PEs and ABRs in that area 💜

Here's an example diagram for inter-AS segmentation 🦋:

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

okay so the inter-AS segmentation procedures we've got so far ([RFC6513], [RFC6514], [RFC7117], and Section 5 of this document) need all the ASBRs to be involved 😭, and ingress replication is used between two ASBRs in different ASes 🔥

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

As the diagram below shows, ASBR2/3 will establish a multihop EBGP session, either with a 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 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 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 Aggregation

ngl this part is kind of a big deal 👑. Every I/S-PMSI route from each PE gets propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-D routes, depending on the types of tunnels used in each region. That can mean way too many routes and tunnels 😵. To fix this, the I-PMSI routes from all PEs in 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 gets switched into the single I-PMSI tunnel. It's giving the same vibe as the MVPN Inter-AS I-PMSI route originated by ASBRs 💖

The MVPN Inter-AS I-PMSI A-D route could honestly be called a "per-AS I-PMSI A-D route", to compare it against the (per-PE) Intra-AS I-PMSI A-D routes originated by each PE. In this document, we'll call it a "per-region I-PMSI A-D route" when we want to aggregate 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, each one will advertise such a route, with the same Region ID and Ethernet Tag ID (Section 3.1). Just like the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route from all those re-advertised by the upstream RBRs, so they'll only receive traffic injected by one of them 🫶

MVPNs don't aggregate S-PMSI routes from all PEs in an AS the way they do for I-PMSI routes, because the number of PEs advertising S-PMSI routes for the same (S,G) or (*,G) is small 🌈. The same goes for EVPNs, so there are no per-region S-PMSI routes 🙅‍♀️

Also, per-region I-PMSI routes can be used to deal with 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 ✨:

  • For a two-octet AS number, use a Transitive Two-Octet 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.
  • For a four-octet AS number, use a Transitive Four-Octet 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.
  • For an area ID, use a Transitive 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.

The use of other EC encodings MAY be allowed, as long as they uniquely identify the region and the RBRs for the same region use the same Region ID 🍓

6.3. Use of S-NH-EC

[RFC7524] specifies the S-NH-EC because it doesn't let ABRs change the BGP next hop when they re-advertise I/S-PMSI A-D routes to downstream areas 🙈. That behavior is only there to stay consistent with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be changed when the segmenting ABRs re-advertise them, for reasons specific to MVPNs. For EVPNs, it's perfectly fine to change the next hop when RBRs re-advertise I/S-PMSI A-D routes, so we don't have to rely on the S-NH-EC 💅. So this document specifies that RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D routes and don't use the S-NH-EC. The win here is that neither ingress PEs nor egress PEs need to understand or use the S-NH-EC, and one consistent procedure (based on BGP next hops) works for both inter-AS and inter-region segmentation 🔥

If a downstream PE/RBR needs to originate Leaf A-D routes, it builds an IP-based Route Target Extended Community. It does this by putting the IP address carried in the Next Hop of the received I/S-PMSI A-D route into the Global Administrator field, with the Local Administrator field of that extended community set to 0. It then sets the Extended Communities attribute of the Leaf A-D route to that extended community 🎀

Similar to [RFC7524], the upstream RBR MUST (auto-)configure 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 technique, the mechanisms specified in [RFC4684] for constrained BGP route distribution can be used alongside this specification, so only the needed PE/ABR has to process a particular Leaf A-D route 🦋

6.4. Ingress PE's I-PMSI Leaf Tracking

[RFC7524] says that when an ingress PE/ASBR (re-)advertises a VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA 🧐. Similar to the inter-AS case, this isn't really needed for EVPNs. To stay consistent with the inter-AS case, the ingress PE does not set the L flag in its originated I-PMSI A-D routes. It figures out 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 issue exists, and the same solution as the inter-AS case applies, as specified in Section 5.3 💜

7. Multihoming Support

To support multihoming with segmentation, Ethernet Segment Identifier (ESI) labels SHOULD be allocated from a "Domain-wide Common Block" (DCB) [RFC9573] for all tunnel types, including Ingress Replication tunnels [RFC7988] 🌸. Through means outside the scope of this document, PEs know that ESI labels come from a DCB, and existing multihoming procedures will then work "as is" (whether or not a multihomed Ethernet Segment spans segmentation regions) 🫶

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

8. IANA Considerations

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

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

              Table 3: New Route Types

IANA has also assigned one flag bit from the "Multicast Flags Extended Community" registry created by [RFC9251] 🔥:

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

           Table 4: New Multicast Flag

9. Security Considerations

🚨 This part is serious, bestie, so read it carefully 🚨

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

10. References

10.1. Normative References 📚💖

Okay bestie, these are the ones you actually need to read first 🤓✨

10.2. Informative References 🌸

These ones are the background reading, the "wait, what's that?" docs 🧚

Acknowledgements 🫶

The authors thank Eric Rosen, John Drake, and Ron Bonica for their comments and suggestions. Big love to them 💜

Contributors 💅

The following people also contributed to this document through their earlier work in EVPN selective multicast. Queens, all of them 👑

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 🦋

Meet the people who wrote this whole thing 🎀

Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net

Wen Lin
Juniper Networks
Email: wlin@juniper.net

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

Keyur Patel
Arrcus
Email: keyur@arrcus.com

Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com
📦 where this page comes from