rfc9856.original   rfc9856.txt 
BESS Workgroup J. Rabadan, Ed. Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Internet-Draft J. Kotalwar Request for Comments: 9856 J. Kotalwar
Intended status: Standards Track S. Sathappan Category: Standards Track S. Sathappan
Expires: 18 August 2025 Nokia ISSN: 2070-1721 Nokia
Z. Zhang Z. Zhang
W. Lin W. Lin
Juniper Juniper
14 February 2025 September 2025
Multicast Source Redundancy in EVPN Networks Multicast Source Redundancy in EVPNs
draft-ietf-bess-evpn-redundant-mcast-source-15
Abstract Abstract
In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic
replication and delivery play a crucial role in enabling efficient replication and delivery play a crucial role in enabling efficient
and scalable layer-2 and layer-3 services. A common deployment and scalable Layer 2 and Layer 3 services. A common deployment
scenario involves redundant multicast sources that ensure high scenario involves redundant multicast sources that ensure high
availability and resiliency. However, the presence of redundant availability and resiliency. However, the presence of redundant
sources can lead to duplicate IP multicast traffic in the network, sources can lead to duplicate IP multicast traffic in the network,
causing inefficiencies and increased overhead. This document causing inefficiencies and increased overhead. This document
specifies extensions to the EVPN multicast procedures that allow for specifies extensions to the EVPN multicast procedures that allow for
the suppression of duplicate IP multicast traffic from redundant the suppression of duplicate IP multicast traffic from redundant
sources. The proposed mechanisms enhance EVPN's capability to sources. The proposed mechanisms enhance the EVPN's capability to
deliver multicast traffic efficiently while maintaining high deliver multicast traffic efficiently while maintaining high
availability. These extensions are applicable to various EVPN availability. These extensions are applicable to various EVPN
deployment scenarios and provide guidelines to ensure consistent and deployment scenarios and provide guidelines to ensure consistent and
predictable behavior across diverse network topologies. predictable behavior across diverse network topologies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 18 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9856.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Background on IP Multicast Delivery in EVPN Networks . . 7 1.2. Background on IP Multicast Delivery in EVPN Networks
1.2.1. Intra-subnet IP Multicast Forwarding . . . . . . . . 7 1.2.1. Intra-Subnet IP Multicast Forwarding
1.2.2. Inter-subnet IP Multicast Forwarding . . . . . . . . 9 1.2.2. Inter-Subnet IP Multicast Forwarding
1.3. Multi-Homed IP Multicast Sources in EVPN . . . . . . . . 11 1.3. Multi-Homed IP Multicast Sources in EVPN
1.4. The Need for Redundant IP Multicast Sources in EVPN . . . 12 1.4. The Need for Redundant IP Multicast Sources in EVPN
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 13 2. Solution Overview
2.1. Warm Standby Solution . . . . . . . . . . . . . . . . . . 13 2.1. Warm Standby Solution
2.2. Hot Standby Solution . . . . . . . . . . . . . . . . . . 14 2.2. Hot Standby Solution
2.3. Solution Selection . . . . . . . . . . . . . . . . . . . 14 2.3. Solution Selection
2.4. System Support . . . . . . . . . . . . . . . . . . . . . 15 2.4. System Support
3. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . 15 3. BGP EVPN Extensions
3.1. Single Flow Group Flag in the Multicast Flags Extended 3.1. Single Flow Group Flag in the Multicast Flags Extended
Community . . . . . . . . . . . . . . . . . . . . . . . . 15 Community
3.2. ESI Label Extended Community in S-PMSI A-D Routes . . . . 15 3.2. ESI Label Extended Community in S-PMSI A-D Routes
4. Warm Standby (WS) Solution for Redundant G-Sources . . . . . 16 4. Warm Standby (WS) Solution for Redundant G-Sources
4.1. Specification . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Specification
4.2. Warm Standby Example in an OISM Network . . . . . . . . . 19 4.2. Warm Standby Example in an OISM Network
4.3. Warm Standby Example in a Single-BD Tenant Network . . . 21 4.3. Warm Standby Example in a Single-BD Tenant Network
5. Hot Standby Solution for Redundant G-Sources . . . . . . . . 22 5. Hot Standby Solution for Redundant G-Sources
5.1. Specification . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Specification
5.2. Extensions for the Advertisement of DCB Labels . . . . . 26 5.2. Extensions for the Advertisement of DCB Labels
5.3. Use of BFD in the HS Solution . . . . . . . . . . . . . . 27 5.3. Use of BFD in the HS Solution
5.4. Hot Standby Example in an OISM Network . . . . . . . . . 28 5.4. Hot Standby Example in an OISM Network
5.4.1. Multi-Homed Redundant G-Sources . . . . . . . . . . . 28 5.4.1. Multi-Homed Redundant G-Sources
5.4.2. Single-Homed Redundant G-Sources . . . . . . . . . . 31 5.4.2. Single-Homed Redundant G-Sources
5.5. Hot Standby Example in a Single-BD Tenant Network . . . . 33 5.5. Hot Standby Example in a Single-BD Tenant Network
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 8. References
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 Acknowledgments
10.2. Informative References . . . . . . . . . . . . . . . . . 35 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses
1. Introduction 1. Introduction
Ethernet Virtual Private Networks (EVPN) [RFC7432] support both Ethernet Virtual Private Networks (EVPNs) [RFC7432] support both
intra-subnet and inter-subnet IP multicast forwarding. [RFC9251] intra-subnet and inter-subnet IP multicast forwarding. [RFC9251]
outlines the procedures required to optimize the delivery of IP outlines the procedures required to optimize the delivery of IP
multicast flows when both sources and receivers are connected to the multicast flows when both sources and receivers are connected to the
same EVPN Broadcast Domain. [RFC9625], on the other hand, defines same EVPN Broadcast Domain. [RFC9625], on the other hand, defines
the procedures for supporting inter-subnet IP multicast within a the procedures for supporting inter-subnet IP multicast within a
tenant network, where the IP multicast source and receivers of the tenant network, where the IP multicast source and receivers of the
same multicast flow are connected to different Broadcast Domains same multicast flow are connected to different Broadcast Domains
within the same tenant. within the same tenant.
However, [RFC9251], [RFC9625], and conventional IP multicast However, [RFC9251], [RFC9625], and conventional IP multicast
skipping to change at page 3, line 35 skipping to change at line 124
sources are active), and sources are active), and
2. Each receiver should receive only from one source. 2. Each receiver should receive only from one source.
Existing multicast solutions typically assume that there are no Existing multicast solutions typically assume that there are no
redundant sources sending identical flows to the same IP multicast redundant sources sending identical flows to the same IP multicast
group. In cases where redundant sources do exist, the receiver group. In cases where redundant sources do exist, the receiver
application is expected to handle duplicate packets. application is expected to handle duplicate packets.
In conventional IP multicast networks, such as those running Protocol In conventional IP multicast networks, such as those running Protocol
Independent Multicast (PIM) [RFC7761] or Multicast VPNs (MVPN) Independent Multicast (PIM) [RFC7761] or Multicast Virtual Private
[RFC6513], a workaround is to configure all redundant sources with Network (MVPN) [RFC6513], a workaround is to configure all redundant
the same IP address. This approach ensures that each receiver gets sources with the same IP address. This approach ensures that each
only one flow because: receiver gets only one flow because:
* The RP (Rendezvous Point) in the multicast network always creates * The Rendezvous Point (RP) in the multicast network always creates
(S,G) state for each source. the (S,G) state for each source.
* The Last Hop Router (LHR) may also create (S,G) state. * The Last Hop Router (LHR) may also create the (S,G) state.
* The (S,G) state binds the flow to a source-specific tree rooted at * The (S,G) state binds the flow to a source-specific tree rooted at
the source IP address. When multiple sources share the same IP the source IP address. When multiple sources share the same IP
address, the resulting source-specific trees ensure that each LHR address, the resulting source-specific trees ensure that each LHR
or RP resides on at most one tree. or RP resides on at most one tree.
This workaround, which often uses anycast addresses, is suitable for This workaround, which often uses anycast addresses, is suitable for
warm standby redundancy solutions (Section 4). However, it is not Warm Standby (WS) redundancy solutions (Section 4). However, it is
effective for hot standby redundancy scenarios (Section 5) and not effective for Hot Standby (HS) redundancy scenarios (Section 5),
introduces challenges when sources need to be reachable via IP and it introduces challenges when sources need to be reachable via IP
unicast or when multiple sources with the same IP address are unicast or when multiple sources with the same IP address are
attached to the same Broadcast Domain. In scenarios where multiple attached to the same Broadcast Domain. In scenarios where multiple
multicast sources stream traffic to the same group using EVPN multicast sources stream traffic to the same group using EVPN
Optimized Inter-Subnet Multicast (OISM), there is not necessarily any Optimized Inter-Subnet Multicast (OISM), there is not necessarily any
(S,G) state created for the redundant sources. In such cases, the (S,G) state created for the redundant sources. In such cases, the
Last Hop Routers may only have (*,G) state, and there may not be a Last Hop Routers may only have a (*,G) state, and there may not be an
Rendezvous Point router to create (S,G) state. RP router to create an (S,G) state.
This document extends [RFC9251] and [RFC9625] to address scenarios This document extends [RFC9251] and [RFC9625] to address scenarios
where IP multicast source redundancy exists. Specifically, it where IP multicast source redundancy exists. Specifically, it
defines procedures for EVPN PEs (Provider Edge devices/routers) to defines procedures for EVPN Provider Edge (PE) devices/routers to
ensure that receivers do not experience packet duplication when two ensure that receivers do not experience packet duplication when two
or more sources send identical IP multicast flows into the tenant or more sources send identical IP multicast flows into the tenant
domain. These procedures are limited to the context of [RFC9251] and domain. These procedures are limited to the context of [RFC9251] and
[RFC9625]; handling redundant sources in other multicast solutions is [RFC9625]; handling redundant sources in other multicast solutions is
beyond the scope of this document. beyond the scope of this document.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
* Broadcast Domain (BD): an emulated Ethernet, such that two systems BD: Broadcast Domain. An emulated Ethernet, such that two systems
on the same BD will receive each other's link-local broadcasts. on the same BD will receive each other's link-local broadcasts.
In this document, BD also refers to the instantiation of a In this document, "BD" also refers to the instantiation of a
Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one
or multiple BDs of the same tenant. or multiple BDs of the same tenant.
* BUM: Broadcast, Unknown unicast, and Multicast traffic. BUM: Broadcast, Unknown Unicast, and Multicast traffic.
* Designated Forwarder (DF): as defined in [RFC7432], an Ethernet DF: Designated Forwarder. As defined in [RFC7432], an Ethernet
Segment may be multi-homed (attached to more than one PE). An Segment (ES) may be multi-homed (attached to more than one PE).
Ethernet Segment may also contain multiple BDs, of one or more An ES may also contain multiple BDs of one or more EVIs. For each
EVIs. For each such EVI, one of the PEs attached to the segment such EVI, one of the PEs attached to the segment becomes that
becomes that EVI's DF for that segment. Since a BD may belong to EVI's DF for that segment. Since a BD may belong to only one EVI,
only one EVI, we can speak unambiguously of the BD's DF for a we can speak unambiguously of the BD's DF for a given segment.
given segment.
* Downstream PE: in this document a Downstream PE is referred to as Downstream PE: In this document, a downstream PE is referred to as
the EVPN PE that is connected to the IP Multicast receivers and the EVPN PE that is connected to the IP Multicast receivers and
gets the IP Multicast flows from remote EVPN PEs. gets the IP Multicast flows from remote EVPN PEs.
* EVI: EVPN Instance. EVI: EVPN Instance.
* G-traffic: any frame with an IP payload whose IP Destination G-traffic: Any frame with an IP payload whose destination IP address
Address (IP DA) is a multicast group G. is a multicast group G.
* G-source: any system sourcing IP multicast traffic to group G. G-source: Any system sourcing IP multicast traffic to group G.
* Hot Standby Redundancy: multicast source redundancy procedure Hot Standby Redundancy: The multicast source redundancy procedure
defined in this document, by which the upstream PEs forward the defined in this document, by which the upstream PEs forward the
redundant multicast flows to the downstream PEs, and the redundant multicast flows to the downstream PEs, and the
downstream PEs make sure only one flow is forwarded to the downstream PEs make sure only one flow is forwarded to the
interested attached receivers. interested attached receivers.
* IGMP: Internet Group Management Protocol [RFC3376]. IGMP: Internet Group Management Protocol [RFC9776].
* Inclusive Multicast Tree or Inclusive Provider Multicast Service I-PMSI: Inclusive Multicast Tree or Inclusive Provider Multicast
Interface (I-PMSI): defined in [RFC6513], in this document it is Service Interface. While defined in [RFC6513], in this document
applicable only to EVPN and refers to the default multicast tree it is only applicable to EVPN and refers to the default multicast
for a given BD. All the EVPN PEs that are attached to a specific tree for a given BD. All the EVPN PEs that are attached to a
BD belong to the I-PMSI for the BD. The I-PMSI trees are signaled specific BD belong to the I-PMSI for the BD. The I-PMSI trees are
by EVPN Inclusive Multicast Ethernet Tag (IMET) routes. signaled by EVPN Inclusive Multicast Ethernet Tag (IMET) routes.
* IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in
[RFC7432]. [RFC7432].
* MLD: Multicast Listener Discovery [RFC3810]. MLD: Multicast Listener Discovery [RFC9777].
* MVPN: Multicast Virtual Private Networks, as in [RFC6513]. MVPN: Multicast Virtual Private Networks, as in [RFC6513].
* OISM: Optimized Inter-Subnet Multicast, as in [RFC9625]. OISM: Optimized Inter-Subnet Multicast, as in [RFC9625].
* PE: Provider Edge. PE: Provider Edge.
* PIM: Protocol Independent Multicast, as in [RFC7761]. PIM: Protocol Independent Multicast, as in [RFC7761].
* P-tunnel: The term "Provider tunnel" refers to the type of tree P-tunnel: The term "Provider tunnel" refers to the type of tree
employed by an upstream EVPN PE to forward multicast traffic to employed by an upstream EVPN PE to forward multicast traffic to
downstream PEs. The P-tunnels supported in this document include downstream PEs. The P-tunnels supported in this document include
Ingress Replication (IR), Assisted Replication (AR) [RFC9574], Bit Ingress Replication (IR), Assisted Replication (AR) [RFC9574], Bit
Indexed Explicit Replication (BIER) [RFC8296], multicast Label Indexed Explicit Replication (BIER) [RFC8296], multicast Label
Distribution Protocol (mLDP), and Point-to-Multi-Point Resource Distribution Protocol (mLDP), and Point-to-Multipoint (P2MP) RSVP
Reservation Protocol with Traffic Engineering extensions (P2MP - Traffic Engineering (RSVP-TE) extensions.
RSVP-TE).
* Redundant G-source: A host or router transmitting a Single Flow Redundant G-source: A host or router transmitting a Single Flow
Group (SFG) within a tenant network, where multiple hosts or Group (SFG) within a tenant network, where multiple hosts or
routers are also transmitting the same SFG. Redundant G-sources routers are also transmitting the same SFG. Redundant G-sources
transmitting the same SFG should have distinct IP addresses; transmitting the same SFG should have distinct IP addresses;
however, they may share the same IP address if located in however, they may share the same IP address if located in
different Broadcast Domains (BDs) within the same tenant network. different Broadcast Domains (BDs) within the same tenant network.
For the purposes of this document, redundant G-sources are assumed For the purposes of this document, redundant G-sources are assumed
not to exhibit "bursty" traffic behavior. to not exhibit "bursty" traffic behavior.
* S-ES and S-ESI: multicast Source Ethernet Segment and multicast S-ES and S-ESI: Multicast Source Ethernet Segment and multicast
Source Ethernet Segment Identifier. The Ethernet Segment and Source Ethernet Segment Identifier. The ES and ESI associated to
Ethernet Segment Identifier associated to a G-source. a G-source.
* Selective Multicast Tree or Selective Provider Multicast Service S-PMSI: Selective Multicast Tree or Selective Provider Multicast
Interface (S-PMSI): As defined in [RFC6513], this term refers to a Service Interface. As defined in [RFC6513], this term refers to a
multicast tree to which only the PEs interested in a specific multicast tree to which only the PEs interested in a specific
Broadcast Domain (BD) belong. In the context of this document, it Broadcast Domain belong. In the context of this document, it is
is specific to EVPN. Two types of EVPN S-PMSIs are supported: specific to EVPN. Two types of EVPN S-PMSIs are supported:
- S-PMSIs with Auto-Discovery Routes: These S-PMSIs require the S-PMSIs with Auto-Discovery routes: These S-PMSIs require the
upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI A-D) upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI A-D)
routes, as described in [RFC9572]. Downstream PEs interested routes, as described in [RFC9572]. Downstream PEs interested
in the multicast traffic join the S-PMSI tree following the in the multicast traffic join the S-PMSI tree following the
procedures specified in [RFC9572]. procedures specified in [RFC9572].
- S-PMSIs without Auto-Discovery Routes: These S-PMSIs do not S-PMSIs without Auto-Discovery Routes: These S-PMSIs do not
require the advertisement of S-PMSI A-D routes. Instead, they require the advertisement of S-PMSI A-D routes. Instead, they
rely on the forwarding information provided by Inclusive rely on the forwarding information provided by IMET routes.
Multicast Ethernet Tag (IMET) routes. Upstream PEs forward IP Upstream PEs forward IP multicast flows only to downstream PEs
multicast flows only to downstream PEs that advertise Selective that advertise Selective Multicast Ethernet Tag (SMET) routes
Multicast Ethernet Tag (SMET) routes for the specific flow. for the specific flow. These S-PMSIs are supported exclusively
These S-PMSIs are supported exclusively with the following with the following P-tunnel types: IR, AR, and BIER.
P-tunnel types: Ingress Replication (IR), Assisted Replication
(AR), and Bit Indexed Explicit Replication (BIER).
* SFG (Single Flow Group): A multicast group that represents traffic SFG: Single Flow Group. A multicast group that represents traffic
containing a single flow. Multiple sources, which may have the containing a single flow. Multiple sources, which may have the
same or different IP addresses, can transmit traffic for an SFG. same or different IP addresses, can transmit traffic for an SFG.
An SFG can be represented in two forms: An SFG can be represented in two forms:
- (*,G): Indicates that any source transmitting multicast traffic (*,G): Indicates that any source transmitting multicast traffic
to group G is considered a redundant G-source for the SFG. to group G is considered a redundant G-source for the SFG.
- (S,G): Indicates that S is a prefix of any length. In this (S,G): Indicates that S is a prefix of any length. In this
representation, a source is deemed a redundant G-source for the representation, a source is deemed a redundant G-source for the
SFG if its address matches the specified prefix S. SFG if its address matches the specified prefix S.
* SMET route: Selective Multicast Ethernet Tag route, as in SMET route: Selective Multicast Ethernet Tag route, as in [RFC9251].
[RFC9251].
* (S,G) and (*,G): used to describe multicast packets or multicast (S,G) and (*,G): Used to describe multicast packets or multicast
state. S stands for Source (IP address of the multicast traffic) state. "S" stands for Source (IP address of the multicast
and G stands for the Group or multicast destination IP address of traffic), and "G" stands for the Group or multicast destination IP
the group. An (S,G) multicast packet refers to an IP packet with address of the group. An (S,G) multicast packet refers to an IP
source IP address "S" and destination IP address "G", and it is packet with source IP address "S" and destination IP address "G",
forwarded on a multicast router if there is a corresponding state and it is forwarded on a multicast router if there is a
for (S,G). A (*,G) multicast packet refers to an IP packet with corresponding state for (S,G). A (*,G) multicast packet refers to
"any" source IP address and a destination IP address "G", and it an IP packet with "any" source IP address and a destination IP
is forwarded on a multicast router based on the existence of the address "G", and it is forwarded on a multicast router based on
corresponding (*,G) state. The document uses variations of these the existence of the corresponding (*,G) state. The document uses
terms. For example, (S1,G1) represents the multicast packets or variations of these terms. For example, (S1,G1) represents the
multicast state for source IP address "S1" and group IP address multicast packets or multicast state for source IP address "S1"
"G1". and group IP address "G1".
* Upstream PE: In this document, an Upstream PE refers to the EVPN Upstream PE: In this document, an upstream PE refers to either the
PE that is either directly connected to the IP multicast source or EVPN PE that is directly connected to the IP multicast source or
is the PE closest to the source. The Upstream PE receives IP the PE closest to the source. The upstream PE receives IP
multicast flows through local Attachment Circuits (ACs). multicast flows through local Attachment Circuits (ACs).
* Warm Standby Redundancy: A multicast source redundancy mechanism Warm Standby Redundancy: A multicast source redundancy mechanism
defined in this document, wherein the upstream PEs connected to defined in this document, wherein the upstream PEs connected to
redundant sources within the same tenant ensure that only one redundant sources within the same tenant ensure that only one
source of a given flow transmits multicast traffic to the source of a given flow transmits multicast traffic to the
interested downstream PEs at any given time. interested downstream PEs at any given time.
This document also assumes familiarity with the terminology of This document also assumes familiarity with the terminology of
[RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251], [RFC9625], [RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251], [RFC9625],
[RFC9136], and [RFC9572]. [RFC9136], and [RFC9572].
1.2. Background on IP Multicast Delivery in EVPN Networks 1.2. Background on IP Multicast Delivery in EVPN Networks
IP multicast facilitates the delivery of a single copy of a packet IP multicast facilitates the delivery of a single copy of a packet
from a source (S) to a group of receivers (G) along a multicast tree. from a source (S) to a group of receivers (G) along a multicast tree.
In an EVPN tenant domain, the multicast tree can be constructed where In an EVPN tenant domain, the multicast tree can be constructed where
the source (S) and the receivers for the multicast group (G) are the source (S) and the receivers for the multicast group (G) are
either connected to the same Broadcast Domain (BD) or to different either connected to the same Broadcast Domain (BD) or to different
Broadcast Domains. The former scenario is referred to as "Intra- Broadcast Domains. The former scenario is referred to as "Intra-
subnet IP Multicast forwarding", while the latter is referred to as subnet IP Multicast forwarding", while the latter is referred to as
"Inter-subnet IP Multicast forwarding". "Inter-subnet IP Multicast forwarding".
1.2.1. Intra-subnet IP Multicast Forwarding 1.2.1. Intra-Subnet IP Multicast Forwarding
When the source S1 and the receivers interested in G1 are connected When the source S1 and the receivers interested in G1 are connected
to the same Broadcast Domain (BD), the EVPN network can deliver IP to the same Broadcast Domain, the EVPN network can deliver IP
multicast traffic to the receivers using two different approaches, as multicast traffic to the receivers using two different approaches, as
illustrated in Figure 1: illustrated in Figure 1:
S1 + S1 + S1 + S1 +
(a) + | (b) + | (a) + | (b) + |
| | (S1,G1) | | (S1,G1) | | (S1,G1) | | (S1,G1)
PE1 | | PE1 | | PE1 | | PE1 | |
+-----+ v +-----+ v +-----+ v +-----+ v
|+---+| |+---+| |+---+| |+---+|
||BD1|| ||BD1|| ||BD1|| ||BD1||
skipping to change at page 8, line 29 skipping to change at line 348
||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1||
|+---+| |-----| |-----| |+---+| |+---+| |+---+| |+---+| |-----| |-----| |+---+| |+---+| |+---+|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
PE2| PE3| PE4| PE2| PE3| PE4 PE2| PE3| PE4| PE2| PE3| PE4
- | - - - | - | - | - - - | - - | - - - | - | - | - - - | -
| | | | | | | | | | | | | | | | | |
v v v v v v v v v v
| R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - - - - - G1- - - - - - G1- - -
Figure 1: Intra-subnet IP Multicast Figure 1: Intra-Subnet IP Multicast
* Model (a): IP Multicast Delivery as BUM Traffic Model (a): IP Multicast Delivery as BUM Traffic
The upstream PE sends the IP Multicast flows to all downstream The upstream PE sends the IP Multicast flows to all downstream
PEs, even to PEs with non-interested receivers, such as, e.g., PE4 PEs, even to PEs with non-interested receivers, such as, e.g., PE4
in Figure 1. To optimize this behavior, downstream PEs can snoop in Figure 1. To optimize this behavior, downstream PEs can snoop
IGMP/MLD messages from receivers to build Layer 2 multicast state. IGMP/MLD messages from receivers to build Layer 2 multicast state.
For instance, PE4 could avoid forwarding (S1,G1) to R3, since R3 For instance, PE4 could avoid forwarding (S1,G1) to R3, since R3
has not expressed interest in (S1,G1). has not expressed interest in (S1,G1).
* Model (b): Optimized Delivery with S-PMSI Model (b): Optimized Delivery with S-PMSI
Model (b) in Figure 1 uses a "Selective Provider Multicast Service Model (b) in Figure 1 uses a "Selective Provider Multicast Service
Interface (S-PMSI)" to optimize the delivery of the (S1,G1) flow. Interface (S-PMSI)" to optimize the delivery of the (S1,G1) flow.
- For example, if PE1 uses "Ingress Replication (IR)", it will * For example, if PE1 uses "IR", it will forward (S1,G1) only to
forward (S1,G1) only to downstream PEs that have issued a downstream PEs that have issued a "SMET" route for (S1,G1),
"Selective Multicast Ethernet Tag (SMET)" route for (S1,G1),
such as PE2 and PE3. such as PE2 and PE3.
- If PE1 uses a P-tunnel type other than IR (e.g., Assisted * If PE1 uses a P-tunnel type other than IR (e.g., AR or BIER),
Replication (AR) or Bit Indexed Explicit Replication (BIER)),
PE1 will advertise an "S-PMSI Auto-Discovery (A-D)" route for PE1 will advertise an "S-PMSI Auto-Discovery (A-D)" route for
(S1,G1). Downstream PEs such as PE2 and PE3 will then join the (S1,G1). Downstream PEs, such as PE2 and PE3, will then join
corresponding multicast tree to receive the flow. the corresponding multicast tree to receive the flow.
Procedures for Model (b) are specified in [RFC9251]. Procedures for Model (b) are specified in [RFC9251] and [RFC9572].
1.2.2. Inter-subnet IP Multicast Forwarding 1.2.2. Inter-Subnet IP Multicast Forwarding
When the sources and receivers are connected to different BDs within When the sources and receivers are connected to different BDs within
the same tenant domain, the EVPN network can deliver IP multicast the same tenant domain, the EVPN network can deliver IP multicast
traffic using either Inclusive or Selective Multicast Trees, as traffic using either Inclusive or Selective Multicast Trees, as
illustrated in Figure 2 with models (a) and (b), respectively. illustrated in Figure 2 with models (a) and (b), respectively.
S1 + S1 + S1 + S1 +
(a) + | (b) + | (a) + | (b) + |
| | (S1,G1) | | (S1,G1) | | (S1,G1) | | (S1,G1)
PE1 | | PE1 | | PE1 | | PE1 | |
skipping to change at page 9, line 48 skipping to change at line 410
||BD2|| ||BD3|| ||BD4|| ||BD2|| ||BD3|| ||BD4|| ||BD2|| ||BD3|| ||BD4|| ||BD2|| ||BD3|| ||BD4||
|+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+|
+--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+
PE2| PE3| PE4 PE2| PE3| PE4 PE2| PE3| PE4 PE2| PE3| PE4
- | - - - | - - | - - - | - - | - - - | - - | - - - | -
| | | | | | | | | | | | | | | |
v v v v v v v v
| R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - - - - - G1- - - - - - G1- - -
Figure 2: Inter-subnet IP Multicast Figure 2: Inter-Subnet IP Multicast
As defined in [RFC9625], inter-subnet multicast forwarding in EVPN is As defined in [RFC9625], inter-subnet multicast forwarding in EVPN is
optimized by ensuring IP multicast flows are sent within the context optimized by ensuring IP multicast flows are sent within the context
of the source BD. If a downstream PE is not connected to the source of the source BD. If a downstream PE is not connected to the source
BD, the IP multicast flow is delivered to the Supplementary Broadcast BD, the IP multicast flow is delivered to the Supplementary Broadcast
Domain (SBD), as shown in Figure 2. Domain (SBD), as shown in Figure 2.
* Inclusive and Selective Multicast Trees * Inclusive and Selective Multicast Trees
Model (a): Inclusive Multicast Tree Model (a): Inclusive Multicast Tree
In this model, the Inclusive Multicast Tree for BD1 on PE1 In this model, the Inclusive Multicast Tree for BD1 on PE1
delivers (S1,G1) to all downstream PEs, such as PE2, PE3, and delivers (S1,G1) to all downstream PEs, such as PE2, PE3, and
PE4, in the context of the SBD. Each downstream PE then PE4, in the context of the SBD. Each downstream PE then
locally routes the flow to its Attachment Circuits, ensuring locally routes the flow to its ACs, ensuring delivery to
delivery to interested receivers. interested receivers.
Model (b): Selective Multicast Tree Model (b): Selective Multicast Tree
In this model, PE1 optimizes forwarding by delivering (S1,G1) In this model, PE1 optimizes forwarding by delivering (S1,G1)
only to downstream PEs that explicitly indicate interest in the only to downstream PEs that explicitly indicate interest in the
flow via Selective Multicast Ethernet Tag (SMET) routes. If flow via SMET routes. If the P-tunnel type is "IR", "AR", or
the P-tunnel type is "Ingress Replication (IR)", "Assisted "BIER", PE1 does not need to advertise an S-PMSI A-D route.
Replication (AR)", or "Bit Indexed Explicit Replication
(BIER)", PE1 does not need to advertise an S-PMSI A-D route.
Downstream PEs join the multicast tree based on the SMET routes Downstream PEs join the multicast tree based on the SMET routes
advertised for (S1,G1). advertised for (S1,G1).
* Advantages of [RFC9625] * Advantages of [RFC9625]
[RFC9625] extends the procedures defined in [RFC9251] to [RFC9625] extends the procedures defined in [RFC9251] to support
support both intra- and inter-subnet multicast forwarding for both intra- and inter-subnet multicast forwarding for EVPN. It
EVPN. It ensures that every upstream PE attached to a source ensures that every upstream PE attached to a source is aware of
is aware of all downstream PEs within the same tenant domain all downstream PEs within the same tenant domain that have
that have interest in specific flows. This is achieved through interest in specific flows. This is achieved through the
the advertisement of SMET routes with the SBD Route Target, advertisement of SMET routes with the SBD Route Target, which are
which are imported by all upstream PEs. imported by all upstream PEs.
* Elimination of Complexity * Elimination of Complexity
The inter-subnet multicast mechanism defined in [RFC9625] The inter-subnet multicast mechanism defined in [RFC9625]
eliminates the need for: Rendezvous Points (RP), Shared trees, eliminates the need for: Rendezvous Points (RPs), shared trees,
Upstream Multicast Hop selection, or other complex conventional upstream multicast hop selection, or other complex conventional
multicast routing techniques. multicast routing techniques.
By leveraging the EVPN framework, inter-subnet multicast forwarding By leveraging the EVPN framework, inter-subnet multicast forwarding
achieves efficient delivery without introducing unnecessary overhead achieves efficient delivery without introducing unnecessary overhead
or dependencies on classic IP multicast protocols. or dependencies on classic IP multicast protocols.
1.3. Multi-Homed IP Multicast Sources in EVPN 1.3. Multi-Homed IP Multicast Sources in EVPN
Unlike conventional multicast routing technologies, multi-homed PEs Unlike conventional multicast routing technologies, multi-homed PEs
connected to the same source do not create IP multicast packet connected to the same source do not create IP multicast packet
duplication when utilizing a multi-homed Ethernet Segment. Figure 3 duplication when utilizing a multi-homed ES. Figure 3 illustrates
illustrates this scenario, where two multi-homed PEs (PE1 and PE2) this scenario, where two multi-homed PEs (PE1 and PE2) are attached
are attached to the same source S1. The source S1 is connected via a to the same source S1. The source S1 is connected via a Layer 2
Layer 2 switch (SW1) to an all-active Ethernet Segment (ES-1), with a switch (SW1) to an all-active ES (ES-1), with a Link Aggregation
Link Aggregation Group (LAG) extending to PE1 and PE2. Group (LAG) extending to PE1 and PE2.
S1 S1
| |
v v
+-----+ +-----+
| SW1 | | SW1 |
+-----+ +-----+
+---- | | +---- | |
(S1,G1)| +----+ +----+ (S1,G1)| +----+ +----+
IGMP/MLD | | all-active | IGMP/MLD | | all-active |
skipping to change at page 11, line 52 skipping to change at line 505
| | +---+---+ | | | | +---+---+ | |
+--------------| |VRF| |----------------+ +--------------| |VRF| |----------------+
| +---+---+---+ | | +---+---+---+ |
| |BD2| |BD3| | | |BD2| |BD3| |
| +-|-+ +-|-+ | | +-|-+ +-|-+ |
+---|-------|---+ +---|-------|---+
^ | | ^ ^ | | ^
IGMP/MLD | v v | IGMP/MLD IGMP/MLD | v v | IGMP/MLD
J(*,G1) | R2 R3 | J(S1,G1) J(*,G1) | R2 R3 | J(S1,G1)
Figure 3: All-active Multi-homing and OISM Figure 3: All-Active Multi-Homing and OISM
When S1 transmits the (S1,G1) flow, SW1 selects a single link within When S1 transmits the (S1,G1) flow, SW1 selects a single link within
the all-active Ethernet Segment to forward the flow, as per the all-active ES to forward the flow, as per [RFC7432]. In this
[RFC7432]. In this example, assuming PE1 is the receiving PE for example, assuming PE1 is the receiving PE for BD1, the multicast flow
Broadcast Domain BD1, the multicast flow is forwarded once BD1 is forwarded once BD1 establishes multicast state for (S1,G1) or
establishes multicast state for (S1,G1) or (*,G1). In Figure 3: (*,G1). In Figure 3:
* Receiver R1 receives (S1,G1) directly via the IRB (Integrated * Receiver R1 receives (S1,G1) directly via the IRB (Integrated
Routing and Bridging) interface, defined in [RFC9135], following Routing and Bridging) interface, defined in [RFC9135], following
the procedures in [RFC9625]. the procedures in [RFC9625].
* Receivers R2 and R3, upon issuing IGMP/MLD reports, trigger PE3 to * Receivers R2 and R3, upon issuing IGMP/MLD reports, trigger PE3 to
advertise an SMET (*,G1) route. This creates multicast state in advertise an SMET (*,G1) route. This creates multicast state in
PE1's BD1, enabling PE1 to forward the multicast flow to PE3's PE1's BD1, enabling PE1 to forward the multicast flow to PE3's
SBD. PE3 subsequently delivers the flow to R2 and R3 as defined SBD. PE3 subsequently delivers the flow to R2 and R3 as defined
in [RFC9625]. in [RFC9625].
Requirements for Multi-Homed IP Multicast Sources: Requirements for Multi-Homed IP Multicast Sources:
* When IP multicast source multi-homing is needed, EVPN multi-homed * When IP multicast source multi-homing is needed, EVPN multi-homed
Ethernet Segments MUST be used. ESes MUST be used.
* EVPN multi-homing ensures that only one upstream PE forwards a * EVPN multi-homing ensures that only one upstream PE forwards a
given multicast flow at a time, preventing packet duplication at given multicast flow at a time, preventing packet duplication at
downstream PEs. downstream PEs.
* The SMET route for a multicast flow ensures that all upstream PEs * The SMET route for a multicast flow ensures that all upstream PEs
in the multi-homed Ethernet Segment maintain state for the flow. in the multi-homed ES maintain state for the flow. This allows
This allows for immediate failover, as the backup PE can for immediate failover, as the backup PE can seamlessly take over
seamlessly take over forwarding in case of an upstream PE failure. forwarding in case of an upstream PE failure.
This document assumes that multi-homed PEs connected to the same This document assumes that multi-homed PEs connected to the same
source always utilize multi-homed Ethernet Segments. source always utilize multi-homed ESes.
1.4. The Need for Redundant IP Multicast Sources in EVPN 1.4. The Need for Redundant IP Multicast Sources in EVPN
While multi-homing PEs to the same IP multicast G-source provides a While multi-homing PEs to the same IP multicast G-source provides a
certain level of resiliency, multicast applications are often certain level of resiliency, multicast applications are often
critical in operator networks, necessitating a higher level of critical in operator networks, necessitating a higher level of
redundancy. This document assumes the following: redundancy. This document assumes the following:
a. Redundant G-sources: redundant G-sources for an SFG may exist a. Redundant G-sources: Redundant G-sources for an SFG may exist
within the EVPN tenant network. A redundant G-source is defined within the EVPN tenant network. A redundant G-source is defined
as a host or router transmitting an SFG stream in a tenant as a host or router transmitting an SFG stream in a tenant
network where another host or router is also sending traffic to network where another host or router is also sending traffic to
the same SFG. the same SFG.
b. G-source placement: redundant G-sources may reside in the same BD b. G-source placement: Redundant G-sources may reside in the same BD
or in different BDs of the tenant network. There must be no or in different BDs of the tenant network. There must be no
restrictions on the locations of receiver systems within the restrictions on the locations of receiver systems within the
tenant. tenant.
c. G-source attachment to EVPN PEs: redundant G-sources may be c. G-source attachment to EVPN PEs: Redundant G-sources may be
either single-homed to a single EVPN PE or multi-homed to either single-homed to a single EVPN PE or multi-homed to
multiple EVPN PEs. multiple EVPN PEs.
d. Packet duplication avoidance: the EVPN PEs must ensure that d. Packet duplication avoidance: The EVPN PEs must ensure that
receiver systems do not experience duplicate packets for the same receiver systems do not experience duplicate packets for the same
SFG. SFG.
This framework ensures that EVPN networks can effectively support This framework ensures that EVPN networks can effectively support
redundant multicast sources while maintaining high reliability and redundant multicast sources while maintaining high reliability and
operational efficiency. operational efficiency.
2. Solution Overview 2. Solution Overview
An SFG can be represented as (*,G) if any source transmitting An SFG can be represented as (*,G) if any source transmitting
multicast traffic to group G is considered a redundant G-source. multicast traffic to group G is considered a redundant G-source.
Alternatively, this document allows an SFG to be represented as Alternatively, this document allows an SFG to be represented as
(S,G), where the source IP address S is a prefix of variable length. (S,G), where the source IP address S is a prefix of variable length.
In this case, a source is deemed a redundant G-source for the SFG if In this case, a source is deemed a redundant G-source for the SFG if
its address falls within the specified prefix. The use of variable- its address falls within the specified prefix. In the remainder of
length prefixes in source advertisements via S-PMSI A-D routes is this document, some examples use (*,G) state for brevity. Wherever
permitted in this document only for the specific application of an SFG is represented as (*,G), it should be understood as being
redundant G-sources. interchangeable with (S,G). The use of variable-length prefixes in
source advertisements via S-PMSI A-D routes is permitted in this
document only for the specific application of redundant G-sources.
This document describes two solutions for handling redundant This document describes two solutions for handling redundant
G-sources: G-sources:
* Warm Standby Solution * Warm Standby Solution
* Hot Standby Solution * Hot Standby Solution
2.1. Warm Standby Solution 2.1. Warm Standby Solution
The Warm Standby solution is an upstream PE-based solution, where The Warm Standby solution is an upstream PE-based solution, where
downstream PEs do not participate in the procedures. In this downstream PEs do not participate in the procedures. In this
solution, all upstream PEs connected to redundant G-sources for an solution, all upstream PEs connected to redundant G-sources for an
SFG (*,G) or (S,G) elect a "Single Forwarder (SF)" among themselves. SFG (*,G) or (S,G) elect a "Single Forwarder (SF)" among themselves.
After the Single Forwarder is elected, the upstream PEs apply Reverse After the Single Forwarder is elected, the upstream PEs apply Reverse
Path Forwarding checks to the multicast state for the SFG: Path Forwarding checks to the multicast state for the SFG:
* Non-Single Forwarder Behavior: a non-Single Forwarder upstream PE * Non-Single Forwarder (Non-SF) Behavior: A Non-SF upstream PE
discards all (*,G) or (S,G) packets received over its local discards all (*,G) or (S,G) packets received over its local AC.
Attachment Circuit.
* Single Forwarder Behavior: the Single Forwarder accepts and * Single Forwarder Behavior: The Single Forwarder accepts and
forwards (*,G) or (S,G) packets received on a single local forwards (*,G) or (S,G) packets received on a single local AC for
Attachment Circuit for the SFG. If packets are received on the SFG. If packets are received on multiple local ACs, the
multiple local Attachment Circuits, the Single Forwarder discards Single Forwarder discards packets on all but one. The selection
packets on all but one. The selection of the Attachment Circuit of the AC for forwarding is a local implementation detail.
for forwarding is a local implementation detail.
In the event of a failure of the Single Forwarder, a new Single In the event of a failure of the Single Forwarder, a new Single
Forwarder is elected among the upstream PEs. This election process Forwarder is elected among the upstream PEs. This election process
requires BGP extensions on existing EVPN routes, which are detailed requires BGP extensions on existing EVPN routes, which are detailed
in Section 3 and Section 4. in Sections 3 and 4.
2.2. Hot Standby Solution 2.2. Hot Standby Solution
The Hot Standby solution relies on downstream PEs to prevent The Hot Standby solution relies on downstream PEs to prevent
duplication of SFG packets. Upstream PEs, aware of locally connected duplication of SFG packets. Upstream PEs, aware of locally connected
G-sources, append a unique Ethernet Segment Identifier (ESI) label to G-sources, append a unique ESI label to multicast packets for each
multicast packets for each SFG. Downstream PEs receive SFG packets SFG. Downstream PEs receive SFG packets from all upstream PEs
from all upstream PEs attached to redundant G-sources and avoid attached to redundant G-sources and avoid duplication by performing a
duplication by performing a Reverse Path Forwarding check on the Reverse Path Forwarding check on the (*,G) state for the SFG:
(*,G) state for the SFG:
* Packet Filtering: a downstream PE discards (*,G) packets received * Packet Filtering: A downstream PE discards (*,G) packets received
from the "wrong G-source." from the "wrong G-source."
* Wrong G-source Identification: the "wrong G-source" is identified * Wrong G-source Identification: The "wrong G-source" is identified
using an ESI label that differs from the ESI label associated with using an ESI label that differs from the ESI label associated with
the selected G-source. the selected G-source.
* ESI Label Usage: in this solution, the ESI label is used for * ESI Label Usage: In this solution, the ESI label is used for
"ingress filtering" at the downstream PE, rather than for "egress "ingress filtering" at the downstream PE, rather than for "egress
filtering" as described in [RFC7432]. In [RFC7432], the ESI label filtering" as described in [RFC7432]. In [RFC7432], the ESI label
indicates which egress Attachment Circuits must be excluded when indicates which egress ACs must be excluded when forwarding BUM
forwarding BUM traffic. Here, the ESI label identifies ingress traffic. Here, the ESI label identifies ingress traffic that
traffic that should be discarded by the downstream PE. should be discarded by the downstream PE.
Control plane and data plane extensions to [RFC7432] are required to Control plane and data plane extensions to [RFC7432] are required to
support ESI labels for SFGs forwarded by upstream PEs. Upon failure support ESI labels for SFGs forwarded by upstream PEs. Upon failure
of the selected G-source, the downstream PE switches to a different of the selected G-source, the downstream PE switches to a different
G-source and updates its Reverse Path Forwarding check for the (*,G) G-source and updates its Reverse Path Forwarding check for the (*,G)
state. These extensions and procedures are described in Section 3 state. These extensions and procedures are described in Sections 3
and Section 5. and 5.
2.3. Solution Selection 2.3. Solution Selection
Operators should select a solution based on their specific Operators should select a solution based on their specific
requirements: requirements:
* The Warm Standby solution is more bandwidth-efficient but incurs * The Warm Standby solution is more bandwidth-efficient but incurs
longer failover times in the event of a G-source or upstream PE longer failover times in the event of a G-source or upstream PE
failure. Additionally, only the upstream PEs connected to failure. Additionally, only the upstream PEs connected to
redundant G-sources for the same SFG need to support the new redundant G-sources for the same SFG need to support the new
skipping to change at page 15, line 29 skipping to change at line 673
system. If one solution is implemented, support for the other is system. If one solution is implemented, support for the other is
OPTIONAL. OPTIONAL.
3. BGP EVPN Extensions 3. BGP EVPN Extensions
This document introduces the following BGP EVPN extensions: This document introduces the following BGP EVPN extensions:
3.1. Single Flow Group Flag in the Multicast Flags Extended Community 3.1. Single Flow Group Flag in the Multicast Flags Extended Community
A new Single Flow Group (SFG) flag is defined within the Multicast A new Single Flow Group (SFG) flag is defined within the Multicast
Flags Extended Community. This flag is requested from the IANA Flags Extended Community. This flag has been registered as bit 4 in
registry for "Multicast Flags Extended Community Flag Values". The the "Multicast Flags Extended Community" registry (see Table 1). The
SFG flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single SFG flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single
Flow Group information in the NLRI (BGP EVPN Network Layer Flow Group information in the BGP EVPN Network Layer Reachability
Reachability Information). Information (NLRI).
3.2. ESI Label Extended Community in S-PMSI A-D Routes 3.2. ESI Label Extended Community in S-PMSI A-D Routes
The Hot Standby solution requires the advertisement of one or more The Hot Standby solution requires the advertisement of one or more
ESI Label Extended Communities [RFC7432] alongside the S-PMSI A-D ESI Label Extended Communities [RFC7432] alongside the S-PMSI A-D
routes. These extended communities encode the ESI values associated routes. These extended communities encode the ESI values associated
with an S-PMSI A-D (*,G) or (S,G) route that advertises the presence with an S-PMSI A-D (*,G) or (S,G) route that advertises the presence
of a Single Flow Group. of a Single Flow Group.
Key considerations include: Key considerations include:
1. When advertised with the S-PMSI A-D routes, only the ESI Label 1. When advertised with the S-PMSI A-D routes, only the ESI label
value in the extended community is relevant to the procedures value in the extended community is relevant to the procedures
defined in this document. defined in this document.
2. The Flags field within the extended community MUST be set to 2. The Flags field within the extended community MUST be set to
'0x00' on transmission and MUST be ignored on reception. "0x00" on transmission and MUST be ignored on reception.
[RFC7432] specifies the use of the ESI Label Extended Community in [RFC7432] specifies the use of the ESI Label Extended Community in
conjunction with the A-D per ES route. This document extends the conjunction with the A-D per ES route. This document extends the
applicability of the ESI Label Extended Community by allowing its applicability of the ESI Label Extended Community by allowing its
inclusion multiple times (with different ESI Label values) alongside inclusion multiple times (with different ESI label values) alongside
the EVPN S-PMSI A-D route. These extensions enable the precise the EVPN S-PMSI A-D route. These extensions enable the precise
encoding and advertisement of Single Flow Group-related information, encoding and advertisement of SFG-related information, facilitating
facilitating efficient multicast traffic handling in EVPN networks. efficient multicast traffic handling in EVPN networks.
4. Warm Standby (WS) Solution for Redundant G-Sources 4. Warm Standby (WS) Solution for Redundant G-Sources
This section specifies the Warm Standby (WS) solution for handling This section specifies the Warm Standby solution for handling
redundant multicast sources (G-sources). Note that while the redundant multicast sources (G-sources). Note that while the
examples use IPv4 addresses, the solution supports both IPv4 and IPv6 examples use IPv4 addresses, the solution supports both IPv4 and IPv6
sources. sources.
4.1. Specification 4.1. Specification
The Warm Standby solution follows these general procedures: The Warm Standby solution follows these general procedures:
1. Configuration of the upstream PEs 1. Configuration of the upstream PEs
Upstream PEs, potentially connected to redundant G-sources, are Upstream PEs, potentially connected to redundant G-sources, are
configured to recognize: configured to recognize:
* The multicast groups that carry an SFG in the tenant domain. * The multicast groups that carry an SFG in the tenant domain.
* The local Broadcast Domains that may host redundant G-sources * The local Broadcast Domains that may host redundant G-sources
The SFG configuration applies to either 'any' source, i.e., (*) The SFG configuration applies to either "any" source, i.e., (*)
or to a specific 'source prefix' (e.g., "192.0.2.0/30" or or to a specific "source prefix" (e.g., "192.0.2.0/30" or
"2001:db8::/120"). For instance, if the IPv4 prefix is "2001:db8::/120"). For instance, if the IPv4 prefix is
192.0.2.0/30, the sources 192.0.2.1 and 192.0.2.2 are considered 192.0.2.0/30, the sources 192.0.2.1 and 192.0.2.2 are considered
redundant G-sources for the SFG, while 192.0.2.10 is not. In a redundant G-sources for the SFG, while 192.0.2.10 is not. In a
different example for IPv6, if the prefix is 2001:db8::/120, different example for IPv6, if the prefix is 2001:db8::/120,
sources 2001:db8::1 or 2001:db8::2 are considered redundant sources 2001:db8::1 or 2001:db8::2 are considered redundant
G-sources for the SFG, but 2001:db8:1::1 is not. G-sources for the SFG, but 2001:db8:1::1 is not.
Example Configuration (Figure 4): Example Configuration (Figure 4):
* PE1 is configured to recognize G1 as an SFG for any source, * PE1 is configured to recognize G1 as an SFG for any source,
with potential redundant G-sources attached to Broadcast with potential redundant G-sources attached to BD1 and BD2.
Domains BD1 and BD2.
* Alternatively, PE1 may recognize G1 as an SFG for sources * Alternatively, PE1 may recognize G1 as an SFG for sources
within 192.0.2.0/30 (or 2001:db8::/120), with redundant within 192.0.2.0/30 (or 2001:db8::/120), with redundant
G-sources in BD1 and BD2. G-sources in BD1 and BD2.
2. Signaling the location of a G-source for an SFG 2. Signaling the location of a G-source for an SFG
Upon receiving the first IP multicast packet for a configured SFG Upon receiving the first IP multicast packet for a configured SFG
on a Broadcast Domain, an upstream PE (e.g., PE1): on a Broadcast Domain, an upstream PE (e.g., PE1):
* MUST advertise an S-PMSI A-D route for the SFG: * MUST advertise an S-PMSI A-D route for the SFG:
- An (*,G) route if the SFG is configured for any source. - An (*,G) route if the SFG is configured for any source.
- An (S,G) route (where S can have any prefix length) if the - An (S,G) route (where S can have any prefix length) if the
SFG is configured for a source prefix. SFG is configured for a source prefix.
* MUST include the following attributes in the S-PMSI A-D route: * MUST include the following attributes in the S-PMSI A-D route:
- Route Targets (RTs): the Supplementary Broadcast Domain - Route Targets (RTs): The Broadcast Domain Route Target (BD-
Route Target (SBD-RT), if applicable, and the Broadcast RT) of the BD receiving the traffic and, if applicable, the
Domain Route Target (BD-RT) of the Broadcast Domain Supplementary Broadcast Domain Route Target (SBD-RT), which
receiving the traffic. The SBD-RT is needed so that the is needed so that the route is imported by all PEs attached
route is imported by all PEs attached to the tenant domain to the tenant domain in an OISM solution.
in an OISM solution.
- Multicast Flags Extended Community: that MUST include the - Multicast Flags Extended Community: MUST include the SFG
SFG flag to indicate that the route conveys an SFG. flag to indicate that the route conveys an SFG.
- Designated Forwarder Election Extended Community: specifies - Designated Forwarder Election Extended Community: Specifies
the algorithm and preferences for the Single Forwarder the algorithm and preferences for the Single Forwarder
election, using the Designated Forwarder election defined election, using the DF election defined in [RFC8584].
in [RFC8584].
* Advertises the route: * Advertises the route:
- Without a PMSI Tunnel Attribute if using Ingress - Without a PMSI Tunnel Attribute if using IR, AR, or BIER.
Replication (IR), Assisted Replication (AR), or Bit Indexed
Explicit Replication (BIER).
- With a PMSI Tunnel Attribute for other tunnel types. - With a PMSI Tunnel Attribute for other tunnel types.
* MUST withdraw the S-PMSI A-D route when the SFG traffic * MUST withdraw the S-PMSI A-D route when the SFG traffic
ceases. A timer is RECOMMENDED to detect inactivity and ceases. A timer is RECOMMENDED to detect inactivity and
trigger route withdrawal. trigger route withdrawal.
3. Single Forwarder Election on the upstream PEs 3. Single Forwarder Election on the upstream PEs
If an upstream PE receives one or more S-PMSI A-D routes for the If an upstream PE receives one or more S-PMSI A-D routes for the
same SFG from remote PEs, it performs Single Forwarder Election same SFG from remote PEs, it performs Single Forwarder Election
based on the Designated Forwarder Election Extended Community. based on the Designated Forwarder Election Extended Community.
* Two routes are considered part of the same SFG if they are * Two routes are considered part of the same SFG if they are
advertised for the same tenant and match on the following advertised for the same tenant and match in the following
fields: fields:
- Multicast Source Length - Multicast Source Length
- Multicast Source - Multicast Source
- Multicast Group Length - Multicast Group Length
- Multicast Group - Multicast Group
* Election Rules: * Election Rules:
1. A consistent Designated Forwarder Election Algorithm MUST 1. A consistent DF Election Algorithm MUST be used across all
be used across all upstream PEs for the Single Forwarder upstream PEs for the Single Forwarder election. In OISM
election. In OISM networks, the Default Designated networks, the Default Designated Forwarder Election
Forwarder Election Algorithm MUST NOT be used if redundant Algorithm MUST NOT be used if redundant G-sources are
G-sources are attached to Broadcast Domains with different attached to Broadcast Domains with different Ethernet
Ethernet Tags. Tags.
2. In case of a mismatch in the Designated Forwarder Election 2. In case of a mismatch in the DF Election Algorithm or
Algorithm or capabilities, the tie-breaker is the lowest capabilities, the tie-breaker is the lowest PE IP address
PE IP address (as advertised in the Originator Address (as advertised in the Originator Address field of the
field of the S-PMSI A-D route). S-PMSI A-D route).
4. Reverse Path Forwarding Checks on Upstream PEs 4. Reverse Path Forwarding Checks on the Upstream PEs
All PEs with a local G-source for an SFG apply a Reverse Path All PEs with a local G-source for an SFG apply a Reverse Path
Forwarding check to the (*,G) or (S,G) state based on the Single Forwarding check to the (*,G) or (S,G) state based on the Single
Forwarder election result: Forwarder election result:
1. Non-Single Forwarder PEs: MUST discard all (*,G) or (S,G) 1. Non-SF PEs: MUST discard all (*,G) or (S,G) packets received
packets received on local Attachment Circuits. on local ACs.
2. Single Forwarder PEs: MUST forward (*,G) or (S,G) packets 2. Single Forwarder PEs: MUST forward (*,G) or (S,G) packets
received on one (and only one) local Attachment Circuit. received on one (and only one) local AC.
Key Features of the Warm Standby Solution: Key Features of the Warm Standby Solution:
* The solution ensures redundancy for SFGs without requiring * The solution ensures redundancy for SFGs without requiring
upgrades to downstream PEs (where no redundant G-sources are upgrades to downstream PEs (where no redundant G-sources are
connected). connected).
* Existing procedures for non-SFG G-sources remain unchanged. * Existing procedures for Non-SFG G-sources remain unchanged.
* Redundant G-sources can be either single-homed or multi-homed. * Redundant G-sources can be either single-homed or multi-homed.
Multi-homing does not alter the above procedures. Multi-homing does not alter the above procedures.
Examples of the Warm Standby solution are provided in Section 4.2 and Examples of the Warm Standby solution are provided in Sections 4.2
Section 4.3. and 4.3.
4.2. Warm Standby Example in an OISM Network 4.2. Warm Standby Example in an OISM Network
Figure 4 illustrates an example where S1 and S2 are redundant Figure 4 illustrates an example where S1 and S2 are redundant
G-sources for the Single Flow Group (*,G1). G-sources for the Single Flow Group (*,G1).
S1 (Single S2 S1 (Single S2
| Forwarder) | | Forwarder) |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
skipping to change at page 20, line 5 skipping to change at line 884
Figure 4: Warm Standby Solution for Redundant G-Sources Figure 4: Warm Standby Solution for Redundant G-Sources
The Warm Standby procedure is as follows: The Warm Standby procedure is as follows:
1. Configuration of the upstream PEs (PE1 and PE2) 1. Configuration of the upstream PEs (PE1 and PE2)
* PE1 and PE2 are configured to recognize G1 as a Single Flow * PE1 and PE2 are configured to recognize G1 as a Single Flow
Group for any source. Group for any source.
* Redundant G-sources for G1 may be attached to Broadcast * Redundant G-sources for G1 may be attached to BD1 (for PE1)
Domains BD1 (for PE1) and BD2 (for PE2). and BD2 (for PE2).
2. Signaling the location of S1 and S2 for (*,G1) 2. Signaling the location of S1 and S2 for (*,G1)
Upon receiving traffic for G1 on a local Attachment Circuit: Upon receiving traffic for G1 on a local AC:
* PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including: * PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including:
- The Supplementary Broadcast Domain Route Target (SBD-RT), - the SBD-RT,
- The Designated Forwarder Election Extended Community, and - the Designated Forwarder Election Extended Community, and
- The SFG flag in the Multicast Flags Extended Community. - the SFG flag in the Multicast Flags Extended Community.
* These routes indicate the presence of a Single Flow Group. * These routes indicate the presence of a Single Flow Group.
3. Single Forwarder Election 3. Single Forwarder Election
* Based on the Designated Forwarder Election Extended Community, * Based on the Designated Forwarder Election Extended Community,
PE1 and PE2 perform Single Forwarder election. PE1 and PE2 perform Single Forwarder election.
* Assuming they use Preference-based Election * Assuming they use Preference-based Election [RFC9785], PE1
[I-D.ietf-bess-evpn-pref-df], PE1 (with a higher preference) (with a higher preference) is elected as the Single Forwarder
is elected as the Single Forwarder for (*,G1). for (*,G1).
4. Reverse Path Forwarding check on the PEs attached to a redundant 4. Reverse Path Forwarding check on the PEs attached to a redundant
G-source G-source
a. Non-Single Forwarder Behavior: PE2 discards all (*,G1) a. Non-SF Behavior: PE2 discards all (*,G1) packets received on
packets received on its local Attachment Circuit. its local AC.
b. Single Forwarder Behavior: PE1 forwards (*,G1) packets b. Single Forwarder Behavior: PE1 forwards (*,G1) packets
received on one (and only one) local Attachment Circuit. received on one (and only one) local AC.
The outcome: The outcome:
* Upon receiving IGMP/MLD reports for (*,G1) or (S,G1), downstream * Upon receiving IGMP/MLD reports for (*,G1) or (S,G1), downstream
PEs (PE3 and PE5) issue SMET routes to pull the multicast Single PEs (PE3 and PE5) issue SMET routes to pull the multicast Single
Flow Group traffic from PE1 only. Flow Group traffic from PE1 only.
* In the event of a failure of S1, the Attachment Circuit connected * In the event of a failure of S1, the AC connected to S1, or PE1
to S1, or PE1 itself, the S-PMSI A-D route for (*,G1) is withdrawn itself, the S-PMSI A-D route for (*,G1) is withdrawn by PE1.
by PE1.
* As a result, PE2 is promoted to Single Forwarder, ensuring * As a result, PE2 is promoted to Single Forwarder, ensuring
continued delivery of (*,G1) traffic. continued delivery of (*,G1) traffic.
4.3. Warm Standby Example in a Single-BD Tenant Network 4.3. Warm Standby Example in a Single-BD Tenant Network
Figure 5 illustrates an example where S1 and S2 are redundant Figure 5 illustrates an example where S1 and S2 are redundant
G-sources for the Single Flow Group (*,G1). In this case, all G-sources for the Single Flow Group (*,G1). In this case, all
G-sources and receivers are connected to the same Broadcast Domain G-sources and receivers are connected to the same BD1, and there is
(BD1), and there is no Supplementary Broadcast Domain (SBD). no SBD.
S1 (Single S2 S1 (Single S2
| Forwarder) | | Forwarder) |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
PE1 | PE2 | PE1 | PE2 |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
S-PMSI | +---+ | | +---+ | S-PMSI S-PMSI | +---+ | | +---+ | S-PMSI
(*,G1) | |BD1| | | |BD1| | (*,G1) (*,G1) | |BD1| | | |BD1| | (*,G1)
Pref200 | +---+ | | +---+ | Pref100 Pref200 | +---+ | | +---+ | Pref100
skipping to change at page 21, line 45 skipping to change at line 971
| |BD1| |-------| |BD1| |------| +--->|BD1| | | |BD1| |-------| |BD1| |------| +--->|BD1| |
| +---+ | | +---+ | | +---+ | | +---+ | | +---+ | | +---+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 5: WS Solution for Redundant G-Sources in the same BD Figure 5: WS Solution for Redundant G-Sources in the Same BD
The procedures for the Warm Standby solution in this example are The procedures for the Warm Standby solution in this example are
identical to those described in Section 4.2, with the following identical to those described in Section 4.2, with the following
distinction: distinction:
* Signaling the S-PMSI A-D Routes * Signaling the S-PMSI A-D Routes
- Upon receiving traffic for the Single Flow Group (*,G1), PE1 - Upon receiving traffic for the Single Flow Group (*,G1), PE1
and PE2 advertise S-PMSI A-D routes. and PE2 advertise S-PMSI A-D routes.
- These routes include only the BD1-RT (Broadcast Domain 1 Route - These routes include only the BD1-RT (Broadcast Domain 1 Route
Target) as there is no Supplementary Broadcast Domain (SBD) in Target) as there is no SBD in this scenario.
this scenario.
This example represents a specific sub-case of the broader procedure This example represents a specific sub-case of the broader procedure
detailed in Section 4.2, adapted to a single Broadcast Domain detailed in Section 4.2, adapted to a single Broadcast Domain
environment. The absence of an SBD simplifies the configuration, as environment. The absence of an SBD simplifies the configuration, as
all signaling remains within the context of BD1. all signaling remains within the context of BD1.
5. Hot Standby Solution for Redundant G-Sources 5. Hot Standby Solution for Redundant G-Sources
This section specifies the Hot Standby solution for handling This section specifies the Hot Standby solution for handling
redundant multicast sources (G-sources). The solution supports both redundant multicast sources (G-sources). The solution supports both
skipping to change at page 22, line 35 skipping to change at line 1009
failover in the event of a G-source or upstream PE failure. It failover in the event of a G-source or upstream PE failure. It
assumes that additional bandwidth consumption in the tenant network assumes that additional bandwidth consumption in the tenant network
is acceptable. The procedure is as follows: is acceptable. The procedure is as follows:
1. Configuration of PEs 1. Configuration of PEs
* Upstream PEs are configured to identify Single Flow Groups in * Upstream PEs are configured to identify Single Flow Groups in
the tenant domain. This includes groups for any source or a the tenant domain. This includes groups for any source or a
source prefix containing redundant G-sources. source prefix containing redundant G-sources.
* Each redundant G-source MUST be associated with an Ethernet * Each redundant G-source MUST be associated with an ES on the
Segment on the upstream PEs. This applies to both single- upstream PEs. This applies to both single-homed and multi-
homed and multi-homed G-sources. For both, single-homed and homed G-sources. For both, single-homed and multi-homed
multi-homed G-sources, ESI labels are essential for Reverse G-sources, ESI labels are essential for Reverse Path
Path Forwarding checks on downstream PEs. The term S-ESI is Forwarding checks on downstream PEs. The term S-ESI is used
used to denote the ESI associated with a redundant G-source. to denote the ESI associated with a redundant G-source.
* Unlike the Warm Standby solution, the Hot Standby solution * Unlike the Warm Standby solution, the Hot Standby solution
requires downstream PEs to support the procedure. requires downstream PEs to support the procedure.
* Downstream PEs: * Downstream PEs:
- Do not need explicit configuration for Single Flow Groups - Do not need explicit configuration for Single Flow Groups
or their ESIs (since they get that information from the or their ESIs (since they get that information from the
upstream PEs). upstream PEs).
- Dynamically select an ESI for each Single Flow Group based - Dynamically select an ESI for each Single Flow Group based
on local policy (hence different downstream PEs may select on local policy (hence different downstream PEs may select
different Ethernet Segment Identifiers) and program a different ESIs) and program a Reverse Path Forwarding check
Reverse Path Forwarding check to discard (*,G) or (S,G) to discard (*,G) or (S,G) packets from other ESIs.
packets from other ESIs.
2. Signaling the location of a G-source for a given SFG and its 2. Signaling the location of a G-source for a given SFG and its
association to the local Ethernet Segments association to the local ESes
An upstream PE configured for Hot Standby procedures: An upstream PE configured for Hot Standby procedures:
* MUST advertise an S-PMSI A-D route for each Single Flow Group. * MUST advertise an S-PMSI A-D route for each Single Flow Group.
These routes: These routes:
- Use the Broadcast Domain Route Target (BD-RT) and, if - Use the Broadcast Domain Route Target (BD-RT) and, if
applicable, the Supplementary Broadcast Domain Route Target applicable, the SBD-RT so that the routes are imported in
(SBD-RT) so that the routes are imported in all the PEs of all the PEs of the tenant domain.
the tenant domain.
- MUST include ESI Label Extended Communities to convey the - MUST include ESI Label Extended Communities to convey the
S-ESI labels associated with the Single Flow Group. These S-ESI labels associated with the Single Flow Group. These
ESI-labels match the labels advertised by the EVPN A-D per ESI labels match the labels advertised by the EVPN A-D per
ES routes for each S-ES. ES routes for each S-ES.
* MAY include a PMSI Tunnel Attribute, depending on the tunnel * MAY include a PMSI Tunnel Attribute, depending on the tunnel
type, as specified in the Warm Standby procedure. type, as specified in the Warm Standby procedure.
* MUST trigger the S-PMSI A-D route advertisement based on the * MUST trigger the S-PMSI A-D route advertisement based on the
SFG configuration (and not based on the reception of traffic). SFG configuration (and not based on the reception of traffic).
3. Distribution of DCB ESI-labels and G-source ES routes 3. Distribution of DCB ESI labels and G-source ES routes
* Upstream PEs advertise corresponding EVPN routes: * Upstream PEs advertise corresponding EVPN routes:
- EVPN Ethernet Segment (ES) routes for the local S-ESIs. ES - EVPN ES routes for the local S-ESIs. ES routes are used
routes are used for regular Designated Forwarder Election for regular DF Election for the S-ES. This document does
for the S-ES. This document does not introduce any change not introduce any change in the procedures related to the
in the procedures related to the EVPN ES routes. EVPN ES routes.
- A-D per EVI and A-D per ES routes for tenant-specific - A-D per EVI and A-D per ES routes for tenant-specific
traffic. If the SBD exists, the EVPN A-D per EVI and A-D traffic. If the SBD exists, the EVPN A-D per EVI and A-D
per ES routes MUST include the route target SBD-RT since per ES routes MUST include the route target SBD-RT, since
they have to be imported by all the PEs in the tenant they have to be imported by all the PEs in the tenant
domain. domain.
* ESI Label Procedures: * ESI label procedures:
- The EVPN A-D per ES routes convey the S-ESI labels that the - The EVPN A-D per ES routes convey the S-ESI labels that the
downstream PEs use to implement Reverse Path Forwarding downstream PEs use to implement Reverse Path Forwarding
checks for SFGs. checks for SFGs.
- All packets for a given G-source MUST carry the same S-ESI - All packets for a given G-source MUST carry the same S-ESI
label. For example, if two redundant G-sources are multi- label. For example, if two redundant G-sources are multi-
homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and PE2 homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and PE2
MUST allocate the same ESI label "Lx" for S-ES-1 and they MUST allocate the same ESI label "Lx" for S-ES-1, and they
MUST allocate the same ESI label "Ly" for S-ES-2. In MUST allocate the same ESI label "Ly" for S-ES-2. In
addition, Lx and Ly MUST be different. addition, Lx and Ly MUST be different.
- S-ESI labels are allocated as Domain-wide Common Block - S-ESI labels are allocated as Domain-wide Common Block
(DCB) labels and follow the procedures in [RFC9573]. In (DCB) labels and follow the procedures in [RFC9573]. In
addition, the PE indicates that these ESI labels are DCB addition, the PE indicates that these ESI labels are DCB
labels by using the extensions described in Section 5.2. labels by using the extensions described in Section 5.2.
4. Processing of EVPN A-D per ES/EVI routes and Reverse Path 4. Processing of EVPN A-D per ES/EVI routes and Reverse Path
Forwarding check on the downstream PEs Forwarding check on the downstream PEs
The EVPN A-D per ES/EVI routes are received and imported in all The EVPN A-D per ES/EVI routes are received and imported in all
the PEs in the tenant domain. Downstream PEs process received the PEs in the tenant domain. Downstream PEs process received
EVPN A-D per ES/EVI routes based on their configuration: EVPN A-D per ES/EVI routes based on their configuration:
* The PEs attached to the same Broadcast Domain of the route * The PEs attached to the same Broadcast Domain of the route
target BD-RT that is included in the EVPN A-D per ES/EVI target BD-RT that is included in the EVPN A-D per ES/EVI
routes process the routes as in [RFC7432] and [RFC8584]. If routes process the routes as in [RFC7432] and [RFC8584]. If
the receiving PE is attached to the same Ethernet Segment as the receiving PE is attached to the same ES as indicated in
indicated in the route, [RFC7432] split-horizon procedures are the route, split-horizon procedures [RFC7432] are followed and
followed and the Designated Forwarder Election candidate list the DF Election candidate list is modified as in [RFC8584] if
is modified as in [RFC8584] if the Ethernet Segment supports the ES supports the AC-DF (AC influenced DF) capability.
the AC-DF (Attachment Circuit influenced Designated Forwarder)
capability.
* The PEs that are not attached to the Broadcast Domain * The PEs that are not attached to the Broadcast Domain
identified by the route target BD-RT but are attached to the identified by the BD-RT but are attached to the SBD of the
Supplementary Broadcast Domain of the received route target received SBD-RT MUST import the EVPN A-D per ES/EVI routes and
SBD-RT, MUST import the EVPN A-D per ES/EVI routes and use use them for redundant G-source mass withdrawal, as explained
them for redundant G-source mass withdrawal, as explained
later. later.
* Upon importing EVPN A-D per ES routes corresponding to * Upon importing EVPN A-D per ES routes corresponding to
different S-ESes, a PE MUST select a primary S-ES based on different S-ESes, a PE MUST select a primary S-ES based on
local policy, and add a Reverse Path Forwarding check to the local policy, and add a Reverse Path Forwarding check to the
(*,G) or (S,G) state in the Broadcast Domain or Supplementary (*,G) or (S,G) state in the Broadcast Domain or SBD. This
Broadcast Domain. This Reverse Path Forwarding check discards Reverse Path Forwarding check discards all ingress packets to
all ingress packets to (*,G)/(S,G) that are not received with (*,G)/(S,G) that are not received with the ESI label of the
the ESI-label of the primary S-ES. primary S-ES.
5. G-traffic forwarding for redundant G-sources and fault detection 5. G-traffic forwarding for redundant G-sources and fault detection
* Traffic Forwarding with S-ESI Labels: * Traffic forwarding with S-ESI labels:
- When there is an existing (*,G) or (S,G) state for the SFG - When there is an existing (*,G) or (S,G) state for the SFG
with output interface list entries associated with remote with output interface list entries associated with remote
EVPN PEs, the upstream PE will add an S-ESI label to the EVPN PEs, the upstream PE will add an S-ESI label to the
bottom of the stack when forwarding G-traffic received on bottom of the stack when forwarding G-traffic received on
an S-ES. This label is allocated from a domain-wide common an S-ES. This label is allocated from a DCB as described
block as described in Step 3. in Step 3.
- If Point-to-multipoint or BIER PMSIs are used, this - If point-to-multipoint or BIER PMSIs are used, this
procedure does not introduce new data path requirements on procedure does not introduce new data path requirements on
the upstream PEs, apart from allocating the S-ESI label the upstream PEs, apart from allocating the S-ESI label
from the domain-wide common block as per [RFC9573]). from the DCB as per [RFC9573]). However, when IR or AR are
However, when Ingress Replication or Assisted Replication employed, this document extends the procedures defined in
are employed, this document extends the procedures defined [RFC7432]. In these scenarios, the upstream PE pushes the
in [RFC7432]. In these scenarios, the upstream PE pushes S-ESI labels on packets not only destined for PEs sharing
the S-ESI labels on packets not only destinated for PEs the ES but also for all PEs within the tenant domain. This
sharing the ES but also for all PEs within the tenant ensures that downstream PEs receive all the multicast
domain. This ensures that downstream PEs receive all the packets from the redundant G-sources with an S-ESI label,
multicast packets from the redundant G-sources with an regardless of the PMSI type or local ESes. Downstream PEs
S-ESI label, regardless of the PMSI type or local ESes. will discard any packet carrying an S-ESI label different
Downstream PEs will discard any packet carrying an S-ESI from the primary S-ESI label (associated with the selected
label different from the primary S-ESI label (associated primary S-ES), as outlined in Step 4.
with the selected primary S-ES), as outlined in Step 4.
* Handling Route Withdrawals and Fault Detection * Handling route withdrawals and fault detection
- If the last EVPN A-D per EVI or the last EVPN A-D per ES - If the last EVPN A-D per EVI or the last EVPN A-D per ES
route for the primary S-ES is withdrawn, the downstream PE route for the primary S-ES is withdrawn, the downstream PE
will immediately select a new primary S-ES and update the will immediately select a new primary S-ES and update the
Reverse Path Forwarding check accordingly. Reverse Path Forwarding check accordingly.
- For scenarios where the same S-ES is used across multiple - For scenarios where the same S-ES is used across multiple
tenant domains by the upstream PEs, the withdrawal of all tenant domains by the upstream PEs, the withdrawal of all
the EVPN A-D per-ES routes associated with an S-ES enables the EVPN A-D per-ES routes associated with an S-ES enables
a mass withdrawal mechanism. This allows the downstream PE a mass withdrawal mechanism. This allows the downstream PE
to simultaneously update the Reverse Path Forwarding check to simultaneously update the Reverse Path Forwarding check
for all tenant domains that rely on the same S-ES. for all tenant domains that rely on the same S-ES.
* Removal of Reverse Path Forwarding Checks on S-PMSI Withdrawal * Removal of Reverse Path Forwarding checks on S-PMSI withdrawal
- The withdrawal of the last EVPN S-PMSI A-D route for a - The withdrawal of the last EVPN S-PMSI A-D route for a
given (*,G) or (S,G) that represents an SFG SHOULD result given (*,G) or (S,G) that represents an SFG SHOULD result
in the downstream PE removing the S-ESI label-based Reverse in the downstream PE removing the S-ESI label-based Reverse
Path Forwarding check for that (*,G) or (S,G). Path Forwarding check for that (*,G) or (S,G).
This document supports the use of Context Label Space ID Extended This document supports the use of Context-Specific Label Space ID
Communities, as described in [RFC9573], for scenarios where S-ESI Extended Communities, as described in [RFC9573], for scenarios where
labels are allocated within context label spaces. When the context S-ESI labels are allocated within context-specific label spaces.
label space ID extended community is advertised along with the ESI When the context-specific label space ID extended community is
label in an EVPN A-D per ES route, the ESI label is from a context advertised along with the ESI label in an EVPN A-D per ES route, the
label space identified by the Domain-wide Common Block (DCB) label in ESI label is from a context-specific label space identified by the
the Extended Community. DCB label in the Extended Community.
5.2. Extensions for the Advertisement of DCB Labels 5.2. Extensions for the Advertisement of DCB Labels
Domain-wide Common Block Labels are specified in [RFC9573] and this DCB labels are specified in [RFC9573], and this document makes use of
document makes use of them as outlined in Section 5.1. [RFC9573] them as outlined in Section 5.1. [RFC9573] assumes that DCB labels
assumes that Domain-wide Common Block labels are applicable only to are applicable only to Multipoint-to-Multipoint, Point-to-Multipoint,
Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels. or BIER tunnels. Additionally, it specifies that when a PMSI label
Additionally, it specifies that when a PMSI label is a Domain-wide is a DCB label, the ESI label used for multi-homing is also a DCB
Common Block label, the ESI label used for multi-homing is also a label.
Domain-wide Common Block label.
This document extends the use of DCB-allocated ESI labels with the This document extends the use of DCB-allocated ESI labels with the
following provisions: following provisions:
a. DCB-allocated ESI labels MAY be used with Ingress Replication a. DCB-allocated ESI labels MAY be used with IR tunnels and
tunnels, and
b. DCB-allocated ESI labels MAY be used by PEs that do not use DCB- b. DCB-allocated ESI labels MAY be used by PEs that do not use DCB-
allocated PMSI labels. allocated PMSI labels.
These control plane extensions are indicated in the EVPN A-D per ES These control plane extensions are indicated in the EVPN A-D per ES
routes for the relevant S-ESs by: routes for the relevant S-ESes by:
1. Adding the ESI-DCB-flag (Domain-wide Common Block flag) to the 1. Adding the ESI-DCB-flag (DCB flag) to the ESI label Extended
ESI Label Extended Community, or Community, or
2. Adding the Context Label Space ID extended community 2. Adding the Context-Specific Label Space ID extended community
The encoding of the DCB-flag within the ESI Label Extended Community The encoding of the DCB-flag within the ESI Label Extended Community
is shown below: is shown below:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | ESI Label | | Reserved=0 | ESI Label |
skipping to change at page 27, line 24 skipping to change at line 1227
An ESI label is considered a DCB label if either of the following An ESI label is considered a DCB label if either of the following
conditions is met: conditions is met:
a. The ESI label is encoded in an ESI Label Extended Community with a. The ESI label is encoded in an ESI Label Extended Community with
the ESI-DCB-flag set. the ESI-DCB-flag set.
b. The ESI label is signaled by a PE that has advertised a PMSI b. The ESI label is signaled by a PE that has advertised a PMSI
label that is a DCB label. label that is a DCB label.
As in [RFC9573] this document also permits the use of context label As in [RFC9573], this document also permits the use of context-
space ID extended community. When this extended community is specific label space ID extended community. When this extended
advertised along with the ESI label in an EVPN A-D per ES route, it community is advertised along with the ESI label in an EVPN A-D per
indicates that the ESI label is from a context label space identified ES route, it indicates that the ESI label is from a context-specific
by the DCB label in the Extended Community. label space identified by the DCB label in the Extended Community.
5.3. Use of BFD in the HS Solution 5.3. Use of BFD in the HS Solution
In addition to utilizing the state of the EVPN A-D per EVI, EVPN A-D In addition to utilizing the state of the EVPN A-D per EVI, EVPN A-D
per ES or S-PMSI A-D routes to adjust the Reverse Path Forwarding per ES, or S-PMSI A-D routes to adjust the Reverse Path Forwarding
checks for (*,G) or (S,G) as discussed in Section 5.1, the checks for (*,G) or (S,G) as discussed in Section 5.1, the
Bidirectional Forwarding Detection (BFD) protocol MAY be employed to Bidirectional Forwarding Detection (BFD) protocol MAY be employed to
monitor the status of the multipoint tunnels used to forward the SFG monitor the status of the multipoint tunnels used to forward the SFG
packets from redundant G-sources. packets from redundant G-sources.
BFD integration: BFD integration:
* The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or * The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or
Inclusive Multicast Ethernet Tag routes, depending on whether IMET routes, depending on whether Inclusive PMSI or Selective PMSI
Inclusive PMSI or Selective PMSI trees are being utilized. trees are being utilized.
* The procedures outlined in [I-D.ietf-mpls-p2mp-bfd] are followed * The procedures outlined in [RFC9780] are followed to bootstrap
to bootstrap multipoint BFD sessions on the downstream PEs. multipoint BFD sessions on the downstream PEs.
5.4. Hot Standby Example in an OISM Network 5.4. Hot Standby Example in an OISM Network
This section describes the Hot Standby model applied in an Optimized This section describes the Hot Standby model applied in an Optimized
Inter-Subnet Multicast (OISM) network. Figure 7 and Figure 8 Inter-Subnet Multicast (OISM) network. Figures 7 and 8 illustrate
illustrate scenarios with multi-homed and single-homed redundant scenarios with multi-homed and single-homed redundant G-sources,
G-sources, respectively. respectively.
5.4.1. Multi-Homed Redundant G-Sources 5.4.1. Multi-Homed Redundant G-Sources
Scenario (Figure 7): Scenario (Figure 7):
* S1 and S2 are redundant G-sources for the Single Flow Group * S1 and S2 are redundant G-sources for the Single Flow Group
(*,G1), connected to Broadcast Domain BD1. (*,G1), connected to BD1.
* S1 and S2 are all-active multi-homed to upstream PEs (PE1 and * S1 and S2 are all-active multi-homed to upstream PEs (PE1 and
PE2). PE2).
* Receivers are connected to downstream PEs (PE3 and PE5) in * Receivers are connected to downstream PEs (PE3 and PE5) in BD3 and
Broadcast Domains BD3 and BD1, respectively. BD1, respectively.
* S1 and S2 are connected to the multi-homing PEs using a LAG. * S1 and S2 are connected to the multi-homing PEs using a LAG.
Multicast traffic can traverse either link. Multicast traffic can traverse either link.
* In this model, downstream PEs receive duplicate G-traffic for * In this model, downstream PEs receive duplicate G-traffic for
(*,G1) and must use Reverse Path Forwarding checks to avoid (*,G1) and must use Reverse Path Forwarding checks to avoid
delivering duplicate packets to receivers. delivering duplicate packets to receivers.
S1(ESI-1) S2(ESI-2) S1(ESI-1) S2(ESI-2)
| | | |
skipping to change at page 29, line 39 skipping to change at line 1312
| +---|SBD| +-------| +---|SBD| |--|-|-| +---|SBD| | | +---|SBD| +-------| +---|SBD| |--|-|-| +---|SBD| |
| |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ | | |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ |
|+---+ | | |+---+ | | | | |+---+ | | |+---+ | | |+---+ | | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ | ||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ |
|+---+ | |+---+ | +--->+---+ | |+---+ | |+---+ | +--->+---+ |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 7: HS Solution for Multi-homed Redundant G-Sources in OISM Figure 7: Hot Standby Solution for Multi-Homed Redundant
G-Sources in OISM
The procedure is as follows: The procedure is as follows:
1. Configuration of the PEs: 1. Configuration of the PEs:
* PE1 and PE2 are configured to recognize (*,G1) as a Single * PE1 and PE2 are configured to recognize (*,G1) as a Single
Flow Group. Flow Group.
* Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 for S2. * Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 for S2.
* The Ethernet Segments (ES-1 and ES-2) are configured on both * The ESes (ES-1 and ES-2) are configured on both PEs. ESI
PEs. ESI-labels are allocated from a Domain-wide Common Block labels are allocated from a DCB [RFC9573] - ESI-label-1 for
(DCB) [RFC9573] - ESI-label-1 for ESI-1 and ESI-label-2 for ESI-1 and ESI-label-2 for ESI-2.
ESI-2.
* The downstream PEs, PE3, PE4 and PE5 are configured to support * The downstream PEs (PE3, PE4, and PE5) are configured to
Hot Standby mode and select the G-source with, e.g., lowest support Hot Standby mode and select the G-source with, e.g.,
ESI value. lowest ESI value.
2. Advertisement of the EVPN routes: 2. Advertisement of the EVPN routes:
* PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), including: * PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), including:
- Route Targets: BD1-RT and SBD-RT. - Route Targets: BD1-RT and SBD-RT.
- ESI Label Extended Communities for ESI-label-1 and ESI- - ESI Label Extended Communities for ESI-label-1 and ESI-
label-2. label-2.
- The SFG flag indicating that (*,G1) represents a Single - The SFG flag indicating that (*,G1) represents a Single
Flow Group. Flow Group.
* EVPN ES and A-D per ES/EVI routes are also advertised for * EVPN ES and A-D per ES/EVI routes are also advertised for
ESI-1 and ESI-2. These include SBD-RT for downstream PE ESI-1 and ESI-2. These include SBD-RT for downstream PE
import. The EVPN A-D per ES routes contain ESI-label-1 for import. The EVPN A-D per ES routes contain ESI-label-1 for
ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both
PEs). PEs).
3. Processing of EVPN A-D per ES/EVI routes and Reverse Path 3. Processing of EVPN A-D per ES/EVI routes and Reverse Path
Forwarding check on Downstream PEs: Forwarding check on downstream PEs:
* PE1 and PE2 receive each other's ES and A-D per ES/EVI routes. * PE1 and PE2 receive each other's ES and A-D per ES/EVI routes.
Designated Forwarder Election and programming of the ESI- DF Election and programming of the ESI labels for egress
labels for egress split-horizon filtering follow, as specified split-horizon filtering follow, as specified in [RFC7432] and
in [RFC7432] and [RFC8584]. [RFC8584].
* PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD, PE5 * PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD; PE5
imports them in BD1. imports them in BD1.
* As downstream PEs, PE3 and PE5 use the EVPN A-D per ES/EVI * As downstream PEs, PE3 and PE5 use the EVPN A-D per ES/EVI
routes to program Reverse Path Forwarding checks. routes to program Reverse Path Forwarding checks.
* The primary S-ESI for (*,G1) is selected based on local policy * The primary S-ESI for (*,G1) is selected based on local policy
(e.g., lowest ESI value), and therefore packets with ESI- (e.g., lowest ESI value), and therefore packets with ESI-
label-2 are discarded if ESI-label-1 is selected as the label-2 are discarded if ESI-label-1 is selected as the
primary label. primary label.
skipping to change at page 32, line 38 skipping to change at line 1435
| +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| | | +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| |
| |VRF+---+ | | |VRF+---+ | | | |VRF+---+ | | |VRF+---+ | | |VRF+---+ | | | |VRF+---+ |
|+---+ | | |+---+ | | | |+---+ | | |+---+ | | |+---+ | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ | ||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ |
|+---+ | |+---+ | |+---+ | |+---+ | |+---+ | |+---+ |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 8: HS Solution for single-homed Redundant G-Sources in OISM Figure 8: HS Solution for Single-Homed Redundant G-Sources in OISM
The procedures follow the same logic as described in the multi-homed The procedures follow the same logic as described in the multi-homed
scenario, with the distinction that each ESI is specific to a single scenario, with the distinction that each ESI is specific to a single
PE. PE.
Figure 7 and Figure 8 demonstrate the application of the Hot Standby Figures 7 and 8 demonstrate the application of the Hot Standby
solution, ensuring seamless traffic forwarding while avoiding solution, ensuring seamless traffic forwarding while avoiding
duplication in the presence of redundant G-sources. duplication in the presence of redundant G-sources.
5.5. Hot Standby Example in a Single-BD Tenant Network 5.5. Hot Standby Example in a Single-BD Tenant Network
The Hot Standby procedures described in Section 5.4 apply equally to The Hot Standby procedures described in Section 5.4 apply equally to
scenarios where the tenant network comprises a single Broadcast scenarios where the tenant network comprises a single Broadcast
Domain (e.g., BD1), irrespective of whether the redundant G-sources Domain (e.g., BD1), irrespective of whether the redundant G-sources
are multi-homed or single-homed. In such cases: are multi-homed or single-homed. In such cases:
* The advertised routes do not include the Supplementary Broadcast * The advertised routes do not include the SBD-RT.
Domain Route Target (SBD-RT).
* All procedures are confined to the single Broadcast Domain (BD1). * All procedures are confined to the single BD1.
The absence of the SBD simplifies the configuration and limits the The absence of the SBD simplifies the configuration and limits the
scope of the Hot Standby solution to BD1, while maintaining the scope of the Hot Standby solution to BD1, while maintaining the
integrity of the procedures for managing redundant G-sources. integrity of the procedures for managing redundant G-sources.
6. Security Considerations 6. Security Considerations
The same Security Considerations described in [RFC9625] are valid for The same Security Considerations described in [RFC9625] are valid for
this document. this document.
From a security perspective, out of the two methods described in this From a security perspective, out of the two methods described in this
document, the Warm Standby method is considered lighter in terms of document, the Warm Standby method is considered lighter in terms of
control plane and therefore its impact is low on the processing control plane, and therefore its impact is low on the processing
capabilities of the PEs. The Hot Standby method adds more burden on capabilities of the PEs. The Hot Standby method adds more burden on
the control plane of all the PEs of the tenant with sources and the control plane of all the PEs of the tenant with sources and
receivers. receivers.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate bit 4 in the Multicast Flags Extended IANA has allocated bit 4 in the "Multicast Flags Extended Community"
Community registry that was introduced by [RFC9251]. This bit registry that was introduced by [RFC9251]. This bit indicates that a
indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is given (*,G) or (S,G) in an S-PMSI A-D route is associated with an
associated with an SFG. This bit is called "Single Flow Group" bit SFG. This bit is called "Single Flow Group" bit, and it is defined
and it is defined as follows: as follows:
+=====+===================+===============+ +=====+===================+===============+
| Bit | Name | Reference | | Bit | Name | Reference |
+=====+===================+===============+ +=====+===================+===============+
| 4 | Single Flow Group | This Document | | 4 | Single Flow Group | This Document |
+-----+-------------------+---------------+ +-----+-------------------+---------------+
Table 1 Table 1
IANA is requested to allocate bit 5 in the ESI Label Extended IANA has allocated bit 5 in the "EVPN ESI Label Extended Community
Community Flags registry that was introduced by Flags" registry that was introduced by [RFC9746]. This bit is the
[I-D.ietf-bess-evpn-mh-split-horizon]. This bit is the ESI-DCB flag ESI-DCB flag and indicates that the ESI label contained in the ESI
and indicates that the ESI label contained in the ESI Label Extended Label Extended Community is a DCB label. This bit is defined as
Community is a Domain-wide Common Block label. This bit is defined follows:
as follows:
+=====+==============+===============+
| Bit | Name | Reference |
+=====+==============+===============+
| 5 | ESI-DCB Flag | This Document |
+-----+--------------+---------------+
Table 2
8. Acknowledgments
The authors would like to thank Mankamana Mishra, Ali Sajassi, Greg
Mirsky and Sasha Vainshtein for their review and valuable comments.
Special thanks to Gunter van de Velde for his excellent review, which
significantly enhanced the document’s readability.
9. Contributors
In addition to the authors listed on the front page, the following
people have significantly contributed to this document:
Eric C. Rosen +=====+=========+===============+
| Bit | Name | Reference |
+=====+=========+===============+
| 5 | ESI-DCB | This Document |
+-----+---------+---------------+
Email: erosen52@gmail.com Table 2
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Requirement Levels", BCP 14, RFC 2119,
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February DOI 10.17487/RFC2119, March 1997,
2015, <https://www.rfc-editor.org/info/rfc7432>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
and W. Lin, "Internet Group Management Protocol (IGMP) and Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Multicast Listener Discovery (MLD) Proxies for Ethernet Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, 2015, <https://www.rfc-editor.org/info/rfc7432>.
<https://www.rfc-editor.org/info/rfc9251>.
[RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
(OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2024, <https://www.rfc-editor.org/info/rfc9625>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility", VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019, RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>. <https://www.rfc-editor.org/info/rfc8584>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
Requirement Levels", BCP 14, RFC 2119, and W. Lin, "Internet Group Management Protocol (IGMP) and
DOI 10.17487/RFC2119, March 1997, Multicast Listener Discovery (MLD) Proxies for Ethernet
<https://www.rfc-editor.org/info/rfc2119>. VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
[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>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, [RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", "MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, May 2024, RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>. <https://www.rfc-editor.org/info/rfc9573>.
[I-D.ietf-bess-evpn-mh-split-horizon] [RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan,
Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "BGP J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast
EVPN Multi-Homing Extensions for Split Horizon Filtering", (OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August
Work in Progress, Internet-Draft, draft-ietf-bess-evpn-mh- 2024, <https://www.rfc-editor.org/info/rfc9625>.
split-horizon-11, 17 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-mh-split-horizon-11>.
10.2. Informative References
[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>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. [RFC9746] Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "BGP
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or EVPN Multihoming Extensions for Split-Horizon Filtering",
Multicast (BUM) Procedures", RFC 9572, RFC 9746, DOI 10.17487/RFC9746, March 2025,
DOI 10.17487/RFC9572, May 2024, <https://www.rfc-editor.org/info/rfc9746>.
<https://www.rfc-editor.org/info/rfc9572>.
[I-D.ietf-bess-evpn-pref-df] 8.2. Informative References
Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.
Sajassi, "Preference-based EVPN DF Election", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,
9 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-pref-df-13>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[I-D.ietf-mpls-p2mp-bfd]
Mirsky, G., Mishra, G. S., and D. E. Eastlake,
"Bidirectional Forwarding Detection (BFD) for Multipoint
Networks over Point-to-Multi-Point MPLS Label Switched
Path (LSP)", Work in Progress, Internet-Draft, draft-ietf-
mpls-p2mp-bfd-09, 6 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
p2mp-bfd-09>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>. <https://www.rfc-editor.org/info/rfc9135>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
Thyagarajan, "Internet Group Management Protocol, Version A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc9136>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
for Bit Index Explicit Replication (BIER) in MPLS and Non- Multicast (BUM) Procedures", RFC 9572,
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January DOI 10.17487/RFC9572, May 2024,
2018, <https://www.rfc-editor.org/info/rfc8296>. <https://www.rfc-editor.org/info/rfc9572>.
[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and [RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
A. Sajassi, "Optimized Ingress Replication Solution for A. Sajassi, "Optimized Ingress Replication Solution for
Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574, Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574,
May 2024, <https://www.rfc-editor.org/info/rfc9574>. May 2024, <https://www.rfc-editor.org/info/rfc9574>.
[RFC9776] Haberman, B., Ed., "Internet Group Management Protocol,
Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March
2025, <https://www.rfc-editor.org/info/rfc9776>.
[RFC9777] Haberman, B., Ed., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", STD 101, RFC 9777,
DOI 10.17487/RFC9777, March 2025,
<https://www.rfc-editor.org/info/rfc9777>.
[RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd,
"Bidirectional Forwarding Detection (BFD) for Multipoint
Networks over Point-to-Multipoint MPLS Label Switched
Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025,
<https://www.rfc-editor.org/info/rfc9780>.
[RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
A. Sajassi, "Preference-Based EVPN Designated Forwarder
(DF) Election", RFC 9785, DOI 10.17487/RFC9785, June 2025,
<https://www.rfc-editor.org/info/rfc9785>.
Acknowledgments
The authors would like to thank Mankamana Mishra, Ali Sajassi, Greg
Mirsky, and Sasha Vainshtein for their review and valuable comments.
Special thanks to Gunter Van de Velde for his excellent review, which
significantly enhanced the document's readability.
Contributors
In addition to the authors listed on the front page, the following
person has significantly contributed to this document:
Eric C. Rosen
Email: erosen52@gmail.com
Authors' Addresses Authors' Addresses
Jorge Rabadan (editor) Jorge Rabadan (editor)
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
Sunnyvale, CA 94085 Sunnyvale, CA 94085
United States of America United States of America
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Jayant Kotalwar Jayant Kotalwar
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
Sunnyvale, CA 94085 USA Sunnyvale, CA 94085
United States of America
Email: jayant.kotalwar@nokia.com Email: jayant.kotalwar@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
Sunnyvale, CA 94085 USA Sunnyvale, CA 94085
United States of America
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Email: zzhang@juniper.net Email: zzhang@juniper.net
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
 End of changes. 189 change blocks. 
513 lines changed or deleted 477 lines changed or added

This html diff was produced by rfcdiff 1.48.