| Internet-Draft | EVPN Redundant Sources | June 2023 |
| Rabadan, et al. | Expires 29 December 2023 | [Page] |
Ethernet Virtual Private Network (EVPN) supports intra and inter-subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 December 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Intra and Inter-subnet IP Multicast forwarding are supported in EVPN networks. [RFC9251] describes the procedures required to optimize the delivery of IP Multicast flows when Sources and Receivers are connected to the same EVPN Broadcast Domain, whereas [I-D.ietf-bess-evpn-irb-mcast] specifies the procedures to support Inter-subnet IP Multicast in a tenant network. Inter-subnet IP Multicast means that IP Multicast Source and Receivers of the same multicast flow are connected to different Broadcast Domains of the same tenant.¶
[RFC9251], [I-D.ietf-bess-evpn-irb-mcast] or conventional IP multicast techniques do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source) and b) it is desired that each receiver gets only one of the several flows. Multicast techniques assume there are no redundant sources sending the same flows to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets.¶
As a workaround in conventional IP multicast (that is, networks running PIM or MVPN), if all the redundant sources are given the same IP address, each receiver will get only one flow. The reason is that, in conventional IP multicast, the RP (Rendezvous Point) always creates (S,G) state, and the Last Hop Router (LHR) sometimes creates (S,G) state. The (S,G) state always binds the (S,G) flow to a source-specific tree, rooted at the source IP address. If multiple sources have the same IP address, one may end up with multiple (S,G) trees. However, the way the trees are constructed ensures that any given Last Hop Router or Rendezvous Point router is on at most one of them. The use of an anycast address assigned to multiple sources may be useful for warm standby redundancy solutions (Section 2). However, on one hand, it is not really helpful for hot standby redundancy solutions (Section 2) and on the other hand, configuring the same IP address (in particular, the same IPv4 address) in multiple sources may bring issues if the sources need to be reached by IP unicast traffic or if the sources are attached to the same Broadcast Domain.¶
In addition, in the scenario where several multicast sources streaming traffic to the same group are attached via EVPN/OISM (Optimized Inter-Subnet Multicast), there is not necessarily any (S,G) state created for the redundant sources. The Last Hop Routers may have only (*,G) state, and there may not be a Rendezvous Point router (creating (S,G) state) either. Therefore, this document extends the above two specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication. The procedures to handle redundant sources in solutions different than [RFC9251] or [I-D.ietf-bess-evpn-irb-mcast] are out of the scope of this document.¶
The solution provides support for Warm Standby (WS) and Hot Standby (HS) redundancy. WS is defined as the redundancy scenario in which the upstream PEs, attached to the redundant sources of the same tenant, make sure that only one source of the same flow can send multicast to the interested downstream PEs at the same time. In HS mode, the upstream PEs forward the redundant multicast flows to the downstream PEs, and the downstream PEs make sure only one flow is forwarded to the interested attached receivers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Selective Multicast Tree or Selective Provider Multicast Service Interface (S-PMSI): defined in [RFC6513], in this document it is applicable only to EVPN and refers to the multicast tree to which only the interested PEs of a given BD belong to. There are two types of EVPN S-PMSIs:¶
This document also assumes familiarity with the terminology of [RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251], [I-D.ietf-bess-evpn-irb-mcast], [RFC9136] and [I-D.ietf-bess-evpn-bum-procedure-updates].¶
IP Multicast is all about forwarding a single copy of a packet from a source S to a group of receivers G along a multicast tree. That multicast tree can be created in an EVPN tenant domain where S and the receivers for G are connected to the same Broadcast Domain or different Broadcast Domain. In the former case, we refer to Intra-subnet IP Multicast forwarding, whereas the latter case will be referred to as Inter-subnet IP Multicast forwarding.¶
When the source S1 and receivers interested in G1 are attached to the same Broadcast Domain, the EVPN network can deliver the IP Multicast traffic to the receivers in two different ways (Figure 1):¶
S1 + S1 +
(a) + | (b) + |
| | (S1,G1) | | (S1,G1)
PE1 | | PE1 | |
+-----+ v +-----+ v
|+---+| |+---+|
||BD1|| ||BD1||
|+---+| |+---+|
+-----+ +-----+
+-------|-------+ +-------|
| | | | |
v v v v v
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|+---+| |-----| |-----| |+---+| |+---+| |+---+|
||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1||
|+---+| |-----| |-----| |+---+| |+---+| |+---+|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
PE2| PE3| PE4| PE2| PE3| PE4
- | - - - | - | - | - - - | -
| | | | | | | | |
v v v v v
| R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - -
Model (a) illustrated in Figure 1 is referred to as "IP Multicast delivery as BUM traffic". This way of delivering IP Multicast traffic does not require any extensions to [RFC7432], however, it sends the IP Multicast flows to non-interested receivers, such as e.g., R3 in Figure 1. In this example, downstream PEs can snoop IGMP/MLD messages from the receivers so that layer-2 multicast state is created and, for instance, PE4 can avoid sending (S1,G1) to R3, since R3 is not interested in (S1,G1).¶
Model (b) in Figure 1 uses an S-PMSI to optimize the delivery of the (S1,G1) flow. For instance, assuming PE1 uses IR, PE1 sends (S1,G1) only to the downstream PEs that issued an SMET route for (S1,G1), that is, PE2 and PE3. In case PE1 uses any P-tunnel different than IR, AR or BIER, PE1 will advertise an S-PMSI A-D route for (S1,G1) and PE2/PE2 will join that tree.¶
If the source and receivers are attached to different BDs of the same tenant domain, the EVPN network can also use Inclusive or Selective Trees as depicted in Figure 2, models (a) and (b) respectively.¶
S1 + S1 +
(a) + | (b) + |
| | (S1,G1) | | (S1,G1)
PE1 | | PE1 | |
+-----+ v +-----+ v
|+---+| |+---+|
||BD1|| ||BD1||
|+---+| |+---+|
+-----+ +-----+
+-------|-------+ +-------|
| | | | |
v v v v v
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|+---+| |+---+| |+---+| |+---+| |+---+| |+---+|
||SBD|| ||SBD|| ||SBD|| ||SBD|| ||SBD|| ||SBD||
|+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+|
| VRF | | VRF | | VRF | | VRF | | VRF | | VRF |
|+-v-+| |+-v-+| |+---+| |+-v-+| |+-v-+| |+---+|
||BD2|| ||BD3|| ||BD4|| ||BD2|| ||BD3|| ||BD4||
|+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+|
+--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+
PE2| PE3| PE4 PE2| PE3| PE4
- | - - - | - - | - - - | -
| | | | | | | |
v v v v
| R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - -
[I-D.ietf-bess-evpn-irb-mcast] specifies the procedures to optimize the Inter-subnet Multicast forwarding in an EVPN network. The IP Multicast flows are always sent in the context of the source BD. As described in [I-D.ietf-bess-evpn-irb-mcast], if the downstream PE is not attached to the source BD, the IP Multicast flow is received on the SBD (Supplementary Broadcast Domain), as in the example in Figure 2.¶
[I-D.ietf-bess-evpn-irb-mcast] supports Inclusive or Selective Multicast Trees, and as explained in Section 1.2.1, the Selective Multicast Trees are setup in a different way, depending on the P-tunnel being used by the source Broadcast Domain. As an example, model (a) in Figure 2 illustrates the use of an Inclusive Multicast Tree for Broadcast Domain BD1 on PE1. Since the downstream PEs are not attached to BD1, they will all receive (S1,G1) in the context of the Supplementary Broadcast Domain (SBD) and will locally route the flow to the local Attachment Circuits. Model (b) uses a similar forwarding model, however PE1 sends the (S1,G1) flow in a Selective Multicast Tree. If the P-tunnel is Ingress Replication (IR), Assisted Replication (AR) or Bit Index Explicit Replication (BIER), PE1 does not need to advertise an S-PMSI A-D route.¶
[I-D.ietf-bess-evpn-irb-mcast] is a superset of the procedures in [RFC9251], in which sources and receivers can be in the same or different Broadcast Domain of the same tenant. [I-D.ietf-bess-evpn-irb-mcast] ensures every upstream PE attached to a source will learn of all other PEs (attached to the same Tenant Domain) that have interest in a particular set of flows. This is because the downstream PEs advertise SMET routes for a set of flows with the Supplementary Broadcast Domain's Route Target and they are imported by all the Upstream PEs of the tenant. As a result of that, inter-subnet multicasting can be done within the Tenant Domain, without requiring any Rendezvous Points (RP), shared trees, Upstream Multicast Hop (UMH) selection or any other complex aspects of conventional multicast routing techniques.¶
Contrary to conventional multicast routing technologies, multi-homing PEs attached to the same source can never create IP Multicast packet duplication if the PEs use a multi-homed Ethernet Segment (ES). Figure 3 illustrates this by showing two multi-homing PEs (PE1 and PE2) that are attached to the same source (S1). We assume that S1 is connected to an all-active Ethernet Ssegment by a layer-2 switch (SW1) with a Link Aggregation Group (LAG) to PE1 and PE2.¶
S1
|
v
+-----+
| SW1 |
+-----+
+---- | |
(S1,G1)| +----+ +----+
IGMP | | all-active |
J(S1,G1) PE1 v | ES-1 | PE2
+----> +-----------|---+ +---|-----------+
| +---+ +---+ | | +---+ |
R1 <-----|BD2| |BD1| | | |BD1| |
| +---+---+---+ | | +---+---+ |
+----| |VRF| | | | |VRF| |----+
| | +---+---+ | | | +---+---+ | |
| | |SBD| | | | |SBD| | |
| | +---+ | | | +---+ | |
| +------------|--+ +---------------+ |
| | |
| | |
| | |
| EVPN | ^ |
| OISM v PE3 | SMET |
| +---------------+ | (*,G1) |
| | +---+ | | |
| | |SBD| | |
| | +---+---+ | |
+--------------| |VRF| |----------------+
| +---+---+---+ |
| |BD2| |BD3| |
| +-|-+ +-|-+ |
+---|-------|---+
^ | | ^
IGMP | v v | IGMP
J(*,G1) | R2 R3 | J(S1,G1)
When receiving the (S1,G1) flow from S1, SW1 will choose only one link to send the flow, as per [RFC7432]. Assuming PE1 is the receiving PE on Broadcast Domain BD1, the IP Multicast flow will be forwarded as soon as BD1 creates multicast state for (S1,G1) or (*,G1). In the example of Figure 3, receivers R1, R2 and R3 are interested in the multicast flow to G1. R1 will receive (S1,G1) directly via the IRB interface as per [I-D.ietf-bess-evpn-irb-mcast]. Upon receiving IGMP reports from R2 and R3, PE3 will issue an SMET (*,G1) route that will create state in PE1's Broadcast Domain BD1. PE1 will therefore forward the IP Multicast flow to PE3's SBD and PE3 will forward to R2 and R3, as per [I-D.ietf-bess-evpn-irb-mcast] procedures.¶
When IP Multicast source multi-homing is required, EVPN multi-homed Ethernet Segments MUST be used. EVPN multi-homing guarantees that only one Upstream PE will forward a given multicast flow at the time, avoiding packet duplication at the Downstream PEs. In addition, the SMET route for a given flow creates state in all the multi-homing Upstream PEs. Therefore, in case of failure on the Upstream PE forwarding the flow, the backup Upstream PE can forward the flow immediately.¶
This document assumes that multi-homing PEs attached to the same source always use multi-homed Ethernet Segments.¶
While multi-homing PEs to the same IP Multicast G-source provides certain level of resiliency, multicast applications are often critical in the Operator's network and greater level of redundancy is required. This document assumes that:¶
An Single Flow Group (SFG) is represented as (*,G) if any source that issues multicast traffic to G is a redundant G-source. Alternatively, this document allows a Single Flow Group to be represented as (S,G), where the source IP address "S" is a prefix of any length. In this case, a source is considered a redundant G-source for the Single Flow Group if it is contained in the prefix. This document allows variable length prefixes in the Sources advertised in S-PMSI A-D routes only for the particular application of redundant G-sources.¶
There are two redundant G-source solutions described in this document:¶
The Warm Standby solution is considered an upstream-PE-based solution (since downstream PEs do not participate in the procedures), in which all the upstream PEs attached to redundant G-sources for a Single Flow Group represented by (*,G) or (S,G) will elect a "Single Forwarder" (SF) among themselves. Once a Single Forwarder is elected, the upstream PEs add an Reverse Path Forwarding (RPF) check to the (*,G) or (S,G) state for the Single Flow Group:¶
A failure on the Single Forwarder will result in the election of a new Single Forwarder. The Election requires BGP extensions on the existing EVPN routes. These extensions and associated procedures are described in Section 3 and Section 4 respectively.¶
In the Hot Standby solution the downstream PEs are the ones avoiding the Single Flow Group duplication. The upstream PEs are aware of the locally attached G-sources and add a unique Ethernet Segment Identifier label (ESI-label) per Single Flow Group to the multicast packets forwarded to downstream PEs. The downstream PEs pull the Single Flow Group from all the upstream PEs attached to the redundant G-sources and avoid duplication on the receiver systems by adding a Reverse Path Forwarding check to the (*,G) state for the Single Flow Group:¶
The use of Ethernet Segment Identifier labels for Single Flow Groups forwarded by upstream PEs require some control plane and data plane extensions in the procedures used by [RFC7432] for multi-homing. Upon failure of the selected G-source, the downstream PE will switch over to a different selected G-source, and will therefore change the Reverse Path Forwarding check for the (*,G) state. The extensions and associated procedures are described in Section 3 and Section 5 respectively.¶
An operator should use the Hot Standby solution if they require a fast fail-over time and the additional bandwidth consumption is acceptable (Single Flow Group packets are received multiple times on the downstream PEs). Otherwise the operator should use the Warm Standby solution, at the expense of a slower fail-over time in case of a G-source or upstream PE failure. Besides bandwidth efficiency, another advantage of the Warm Standby solution is that only the upstream PEs attached to the redundant G-sources for the same Single Flow Group need to be upgraded to support the new procedures.¶
This document does not impose the support of both solutions on a system. If one solution is supported, the support of the other solution is OPTIONAL.¶
This document makes use of the following BGP EVPN extensions:¶
Single Flow Group flag in the Multicast Flags Extended Community¶
The Single Flow Group (SFG) flag is a new bit requested to IANA out of the registry Multicast Flags Extended Community Flag Values. This new flag is set for S-PMSI A-D routes that carry a (*,G)/(S,G) Single Flow Group in the NLRI.¶
ESI Label Extended Community is used in S-PMSI A-D routes¶
The Hot Standby solution requires the advertisement of one or more ESI Label Extended Communities [RFC7432] that encode the Ethernet Segment Identifier(s) associated to an S-PMSI A-D (*,G)/(S,G) route that advertises the presence of a Single Flow Group. Only the ESI Label value in the extended community is relevant to the procedures in this document. The Flags field in the extended community will be advertised as 0x00 and ignored on reception. [RFC7432] specifies that the ESI Label Extended Community is advertised along with the A-D per ES route. This documents extends the use of this extended community so that it can be advertised multiple times (with different ESI values) along with the EVPN S-PMSI A-D route.¶
The general procedure is described as follows:¶
Configuration of the upstream PEs¶
Upstream PEs (possibly attached to redundant G-sources) need to be configured to know which groups are carrying only flows from redundant G-sources, that is, the Single Flow Groups (SFGs) in the tenant domain. They will also be configured to know which local Broadcast Domains may be attached to a redundant G-source. The Single Flow Groups can be configured for any source, E.g., SFG for "*", or for a prefix that contains multiple sources that will issue the same SFG, i.e., "10.0.0.0/30". In the latter case sources 10.0.0.1 and 10.0.0.2 are considered as Redundant G-sources, whereas 10.0.0.10 is not considered a redundant G-source for the same SFG.¶
Signaling the location of a G-source for a given Single Flow Group¶
Upon receiving G-traffic for a configured SFG on a Broadcast Domain, an upstream PE configured to follow this procedure, e.g., PE1:¶
The above S-PMSI A-D route MAY be advertised with or without PMSI Tunnel Attribute:¶
Single Forwarder (SF) Election¶
If the PE with a local G-source receives one or more S-PMSI A-D routes for the same Single Flow Group from a remote PE, it will run a Single Forwarder Election based on the information encoded in the Designated Forwarder Election extended community. Two S-PMSI A-D routes are considered for the same SFG if they are advertised for the same tenant, and their Multicast Source Length, Multicast Source, Multicast Group Length and Multicast Group fields match.¶
Reverse Path Forwarding check on the PEs attached to a redundant G-source¶
All the PEs with a local G-source for the Single Flow Group will add a Reverse Path Forwarding check to the (*,G)/(S,G) state for the Single Flow Group. That Reverse Path Forwarding check depends on the Single Forwarder Election result:¶
The solution above provides redundancy for Single Flow Groups and it does not require an upgrade of the downstream PEs (PEs where there is certainty that no redundant G-sources are connected). Other G-sources for non-Single Flow Groups may exist in the same tenant domain. This document does not change the existing procedures for non-Single Flow Group G-sources.¶
The redundant G-sources can be single-homed or multi-homed to a Broadcast Domain in the tenant domain. Multi-homing does not change the above procedures.¶
Section 4.1 and Section 4.2 show two examples of the Warm Standby solution.¶
Figure 4 illustrates an example in which S1 and S2 are redundant G-sources for the Single Flow Group (*,G1).¶
S1 (Single S2
| Forwarder) |
(S1,G1)| (S2,G1)|
| |
PE1 | PE2 |
+--------v---+ +--------v---+
S-PMSI | +---+ | | +---+ | S-PMSI
(*,G1) | +---|BD1| | | +---|BD2| | (*,G1)
Pref200 | |VRF+---+ | | |VRF+---+ | Pref100
|SFG |+---+ | | | |+---+ | | SFG|
| +----|SBD|--+ | |-----------||SBD|--+ |---+ |
v | |+---+ | | |+---+ | | v
| +---------|--+ +------------+ |
SMET | | | SMET
(*,G1) | | (S1,G1) | (*,G1)
| +--------+------------------+ |
^ | | | | ^
| | | EVPN | | |
| | | OISM | | |
| | | | | |
PE3 | | PE4 | | PE5
+--------v---+ +------------+ | +------------+
| +---+ | | +---+ | | | +---+ |
| +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| |
| |VRF+---+ | | |VRF+---+ | | | |VRF+---+ |
|+---+ | | |+---+ | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ |
|+---+ | |+---+ | |+---+ |
+------------+ +------------+ +------------+
| ^ | ^
| | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1)
The Warm Standby solution works as follows:¶
Configuration of the upstream PEs, PE1 and PE2¶
PE1 and PE2 are configured to know that G1 is an Single Flow Group for any source and redundant G-sources for G1 may be attached to Broadcast Domains BD1 or BD2, respectively.¶
Signaling the location of S1 and S2 for (*,G1)¶
Upon receiving (S1,G1) traffic on a local Attachment Circuit, PE1 and PE2 originate S-PMSI A-D (*,G1) routes with the SBD-RT (Supplementary Broadcast Domain Route Target), Designated Forwarder Election Extended Community and a flag indicating that it conveys a Single Flow Group.¶
Single Forwarder (SF) Election¶
Based on the Designated Forwarder Election extended community content, PE1 and PE2 elect a Single Forwarder for (*,G1). Assuming both PEs agree on e.g., Preference based Election as the algorithm to use [I-D.ietf-bess-evpn-pref-df], and PE1 has a higher preference, PE1 becomes the Single Forwarder for (*,G1).¶
Reverse Path Forwarding check on the PEs attached to a redundant G-source¶
The end result is that, upon receiving reports for (*,G1) or (S,G1), the downstream PEs (PE3 and PE5) will issue SMET routes and will pull the multicast Single Flow Group from PE1, and PE1 only. Upon a failure on S1, the Attachment Circuit connected to source S1 or PE1 itself will trigger the S-PMSI A-D (*,G1) withdrawal from PE1 and PE2 will be promoted to Single Forwarder.¶
Figure 5 illustrates an example in which S1 and S2 are redundant G-sources for the Single Flow Group (*,G1), however, now all the G-sources and receivers are connected to the same Broadcast Domain BD1 and there is no Supplementary Broadcast Domain.¶
S1 (Single S2
| Forwarder) |
(S1,G1)| (S2,G1)|
| |
PE1 | PE2 |
+--------v---+ +--------v---+
S-PMSI | +---+ | | +---+ | S-PMSI
(*,G1) | |BD1| | | |BD1| | (*,G1)
Pref200 | +---+ | | +---+ | Pref100
|SFG | | | | | SFG|
| +---| | |-----------| |---+ |
v | | | | | | | v
| +---------|--+ +------------+ |
SMET | | | SMET
(*,G1) | | (S1,G1) | (*,G1)
| +--------+------------------------+ |
^ | | | | ^
| | | EVPN | | |
| | | | | |
| | | | | |
PE3 | | PE4 | | PE5
+--------v---+ +------------+ +-|----------+
| +---+ | | +---+ | | | +---+ |
| |BD1| |-------| |BD1| |------| +--->|BD1| |
| +---+ | | +---+ | | +---+ |
| | | | | |
| | | | | |
| | | | | |
+------------+ +------------+ +------------+
| ^ | ^
| | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1)
The same procedure as in Section 4.1 is valid here, being this a sub-case of the one in Section 4.1. Upon receiving traffic for the Single Flow Group G1, PE1 and PE2 advertise the S-PMSI A-D routes with route target BD1-RT only, since there is no Supplementary Broadcast Domain (SBD).¶
If fast-failover is required upon the failure of a G-source or PE attached to the G-source and the extra bandwidth consumption in the tenant network is not an issue, the Hot Standby solution should be used. The procedure is as follows:¶
Configuration of the PEs¶
As in the Warm Standby case, the upstream PEs where redundant G-sources may exist need to be configured to know which groups (for any source or a prefix containing the intended sources) are carrying only flows from redundant G-sources, that is, the Single Flow Groups in the tenant domain.¶
In addition (and this is not done in Warm Standby mode), the individual redundant G-sources for a Single Flow Group need to be associated with an Ethernet Segment on the upstream PEs. This is irrespective of the redundant G-source being multi-homed or single-homed. Even for single-homed redundant G-sources the Hot Standby procedure relies on the ESI labels for the Reverse Path Forwarding check on downstream PEs. The term "S-ESI" is used in this document to refer to an Ethernet Segment Identifier associated to a redundant G-source.¶
Contrary to what is specified in the Warm Standby method (that is transparent to the downstream PEs), the support of the Hot Standby procedure is required not only on the upstream PEs but also on all downstream PEs connected to the receivers in the tenant network. The downstream PEs do not need to be configured to know the connected Single Flow Groups or their Ethernet Segment Identifiers, since they get that information from the upstream PEs. The downstream PEs will locally select an Ethernet Segment Identifier for a given Single Flow Group, and will program a Reverse Path Forwarding check to the (*,G)/(S,G) state for the Single Flow Group that will discard (*,G)/(S,G) packets from the rest of the Ethernet Segment Identifiers. The selection of the Ethernet Segment Identifier for the Single Flow Group is based on local policy.¶
Signaling the location of a G-source for a given Single Flow Group and its association to the local Ethernet Segments¶
Based on the configuration in step 1, an upstream PE configured to follow the Hot Standby procedures:¶
Distribution of DCB (Domain-wide Common Block) ESI-labels and G-source ES routes¶
An upstream PE advertises the corresponding EVPN ES route, A-D per EVI and A-D per ES routes for the local S-ESIs.¶
Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on the downstream PEs¶
The EVPN A-D per ES/EVI routes are received and imported in all the PEs in the tenant domain. The processing of the EVPN A-D per ES/EVI routes on a given PE depends on its configuration:¶
G-traffic forwarding for redundant G-sources and fault detection¶
Assuming there is (*,G) or (S,G) state for the Single Flow Group with Output Interface list entries associated to remote EVPN PEs, upon receiving G-traffic on a S-ES, the upstream PE will add a S-ESI label at the bottom of the stack before forwarding the traffic to the remote EVPN PEs. This label is allocated from a Domain-wide Common Block as described in step 3. If Point-to-multipoint or BIER PMSIs are used, this is not adding any new data path procedures on the upstream PEs (except that the ESI-label is allocated from a Domain-wide Common Block as described in [I-D.ietf-bess-mvpn-evpn-aggregation-label]). However, if Ingress Replication or Assisted Replication are used, this document extends the [RFC7432] procedures by pushing the S-ESI labels not only on packets sent to the PEs that shared the ES but also to the rest of the PEs in the tenant domain. This allows the downstream PEs to receive all the multicast packets from the redundant G-sources with a S-ESI label (irrespective of the PMSI type and the local ESes), and discard any packet that conveys a S-ESI label different from the primary S-ESI label (that is, the label associated to the selected primary S-ES), as discussed in step 4.¶
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 will immediately select a new primary S-ES and will change the Reverse Path Forwarding check. Note that if the S-ES is re-used for multiple tenant domains by the upstream PEs, the withdrawal of all the EVPN A-D per-ES routes for a S-ES provides a mass withdrawal capability that makes a downstream PE to change the Reverse Path Forwarding check in all the tenant domains using the same S-ES.¶
The withdrawal of the last EVPN S-PMSI A-D route for a given (*,G)/(S,G) that represents a Single Flow Group SHOULD make the downstream PE remove the S-ESI label based Reverse Path Forwarding check on (*,G)/(S,G).¶
Domain-wide Common Block Labels are specified in [I-D.ietf-bess-mvpn-evpn-aggregation-label] and this document makes use of them for the procedures described in Section 5. [I-D.ietf-bess-mvpn-evpn-aggregation-label] assumes that Domain-wide Common Block labels can only be used along with Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels and that, if the PMSI label is signaled as a Domain-wide Common Block label, then the ESI label used for multi-homing is also a Domain-wide Common Block label. This document extends the use of the Domain-wide Common Block allocation for ESI labels so that:¶
This control plane extension is indicated by adding the DCB-flag (Domain-wide Common Block flag) or the Context Label Space ID extended community to the EVPN A-D per ES route(s) advertised for the S-ES. The DCB-flag is encoded in the ESI Label Extended Community as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=0 | ESI Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines the bit 5 in the Flags octet of the ESI Label Extended Community as the ESI-DCB-flag. When the ESI-DCB-flag is set, it indicates that the ESI label is a Domain-wide Common Block label.¶
A received ESI label is considered a Domain-wide Common Block label if either of these two conditions is met:¶
As in [I-D.ietf-bess-mvpn-evpn-aggregation-label] this document also allows the use of context label space ID extended community. When the context label space ID extended community is advertised along with the ESI label in an EVPN A-D per ES route, the ESI label is from a context label space identified by the Domain-wide Common Block label in the Extended Community.¶
In addition to using the state of the EVPN A-D per EVI, EVPN A-D per ES or S-PMSI A-D routes to modify the Reverse Path Forwarding check on (*,G)/(S,G) as discussed in Section 5, Bidirectional Forwarding Detection (BFD) protocol MAY be used to monitor the status of the multipoint tunnels used to forward the Single Flow Group ppackets from the redundant G-sources.¶
The BGP-BFD Attribute is advertised along with the S-PMSI A-D or Inclusive Multicast Ethernet Tag routes (depending on whether Inclusive PMSI or Selective PMSI trees are used) and the procedures described in [I-D.ietf-bess-evpn-bfd] [I-D.ietf-mpls-p2mp-bfd] are used to bootstrap multipoint BFD sessions on the downstream PEs.¶
Figure 7 illustrates the Hot Standby model in an Optimized Inter-Subnet Multicast (OISM) network. Consider S1 and S2 are redundant G-sources for the Single Flow Group (*,G1) in Broadcast Domain BD1 (any source using G1 is assumed to transmit an SFG). S1 and S2 are (all-active) multi-homed to upstream PEs, PE1 and PE2. The receivers are attached to downstream PEs, PE3 and PE5, in Broadcast Domains BD3 and BD1, respectively. S1 and S2 are assumed to be connected by a Link Aggregation Group to the multi-homing PEs, and the multicast traffic can use the link to either upstream PE. The diagram illustrates how S1 sends the G-traffic to PE1 and PE1 forwards to the remote interested downstream PEs, whereas S2 sends to PE2 and PE2 forwards further. In this Hot Standby model, the interested downstream PEs will get duplicate G-traffic from the two G-sources for the same Single Flow Group. While the diagram shows that the two flows are forwarded by different upstream PEs, the all-active multi-homing procedures may cause that the two flows come from the same upstream PE. Therefore, finding out the upstream PE for the flow is not enough for the downstream PEs to program the required Reverse Path Forwarding check to avoid duplicate packets on the receiver.¶
S1(ESI-1) S2(ESI-2)
| |
| +----------------------+
(S1,G1)| | (S2,G1)|
+----------------------+ |
PE1 | | PE2 | |
+--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD1| | (*,G1)
(*,G1) | |VRF+---+ | | |VRF+---+ | SFG
SFG |+---+ | | | |+---+ | | | ESI1,2
ESI1,2 +---||SBD|--+ | |-----------||SBD|--+ | |---+ |
| | |+---+ | | EVPN |+---+ | | | v
v | +---------|--+ OISM +---------|--+ |
| | | |
| | (S1,G1) | |
SMET | +---------+------------------+ | | SMET
(*,G1) | | | | | (*,G1)
^ | | +----------------------------+---+ | ^
| | | | (S2,G1) | | | |
| | | | | | | |
PE3 | | | PE4 | | | PE5
+-------v-v--+ +------------+ | | +------------+
| +---+ | | +---+ | | | | +---+ |
| +---|SBD| +-------| +---|SBD| |--|-|-| +---|SBD| |
| |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ |
|+---+ | | |+---+ | | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ |
|+---+ | |+---+ | +--->+---+ |
+------------+ +------------+ +------------+
| ^ | ^
| | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1)
In this scenario, the Hot Standby solution works as follows:¶
Configuration of the upstream PEs, PE1 and PE2¶
PE1 and PE2 are configured to know that G1 is a Single Flow Group for any source (a source prefix length could have been configured instead) and the redundant G-sources for G1 use S-ESIs ESI-1 and ESI-2 respectively. Both Ethernet Segments are configured in both PEs and their ESI value can be configured or auto-derived. The ESI-label values are allocated from a Domain-wide Common Block [I-D.ietf-bess-mvpn-evpn-aggregation-label] and are configured either locally or by a centralized controller. We assume ESI-1 is configured to use ESI-label-1 and ESI-2 to use ESI-label-2.¶
The downstream PEs, PE3, PE4 and PE5 are configured to support Hot Standby mode and select the G-source with e.g., lowest ESI value.¶
PE1 and PE2 advertise S-PMSI A-D (*,G1) and EVPN ES, A-D per ES and A-D per EVI routes¶
Based on the configuration of step 1, PE1 and PE2 advertise an S-PMSI A-D (*,G1) route each. The route from each of the two PEs will include TWO ESI Label Extended Communities with ESI-1 and ESI-2 respectively, as well as route target BD1-RT plus SBD-RT and a flag that indicates that (*,G1) is a Single Flow Group.¶
In addition, PE1 and PE2 advertise EVPN ES and A-D per ES/EVI routes for ESI-1 and ESI-2. The EVPN A-D per ES and per EVI routes will include the route target of the SBD, i.e.,: SBD-RT, so that they can be imported by the downstream PEs that are not attached to Broadcast Domain BD1, e.g., PE3 and PE4. The EVPN A-D per ES routes will convey ESI-label-1 for ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both PEs).¶
Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check¶
PE1 and PE2 received each other's ES and A-D per ES/EVI routes. Regular [RFC7432] [RFC8584] procedures will be followed for the Designated Forwarder Election and programming of the ESI-labels for egress split-horizon filtering. PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD. Since PE3 has created a (*,G1) state based on local interest, PE3 will add a Reverse Path Forwarding check to (*,G1) so that packets coming with ESI-label-2 are discarded (lowest ESI value is assumed to give the primary S-ES).¶
G-traffic forwarding and fault detection¶
PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within the context of Broadcast Domain BD1. Irrespective of the tunnel type, PE1 pushes ESI-label-1 at the bottom of the stack and the traffic gets to PE3 and PE5 with the mentioned ESI-label (PE4 has no local interested receivers). The G-traffic with ESI-label-1 passes the Reverse Path Forwarding check and it is forwarded to R1. In the same way, PE2 sends (S2,G1) with ESI-label-2, but this G-traffic does not pass the Reverse Path Forwarding check and gets discarded at PE3/PE5.¶
If the link from S1 to PE1 fails, S1 will forward the (S1,G1) traffic to PE2 instead. PE1 withdraws the EVPN ES and A-D routes for ESI-1. Now both flows will be originated by PE2, however the Reverse Path Forwarding checks do not change in PE3/PE5.¶
If subsequently, the link from S1 to PE2 fails, PE2 also withdraws the EVPN ES and A-D routes for ESI-1. Since PE3 and PE5 have no longer A-D per ES/EVI routes for ESI-1, they immediately change the Reverse Path Forwarding check so that packets with ESI-label-2 are now accepted.¶
Figure 8 illustrates a scenario where sources S1 and S2 are single-homed to PE1 and PE2 respectively. This scenario is a sub-case of the one in Figure 7. Now ES-1 only exists in PE1, hence only PE1 advertises the EVPN A-D per ES/EVI routes for ESI-1. Similarly, ES-2 only exists in PE2 and PE2 is the only PE advertising EVPN A-D routes for ESI-2. The same procedures as in Figure 7 apply to this use-case.¶
S1(ESI-1) S2(ESI-2)
| |
(S1,G1)| (S2,G1)|
| |
PE1 | PE2 |
+--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD2| | (*,G1)
(*,G1) | |VRF+---+ | | |VRF+---+ | SFG
SFG |+---+ | | | |+---+ | | | ESI2
ESI1 +---||SBD|--+ | |-----------||SBD|--+ | |---+ |
| | |+---+ | | EVPN |+---+ | | | v
v | +---------|--+ OISM +---------|--+ |
| | | |
| | (S1,G1) | |
SMET | +---------+------------------+ | | SMET
(*,G1) | | | | | (*,G1)
^ | | +--------------------------------+----+ | ^
| | | | (S2,G1) | | | |
| | | | | | | |
PE3 | | | PE4 | | | PE5
+-------v-v--+ +------------+ | +------v-----+
| +---+ | | +---+ | | | +---+ |
| +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| |
| |VRF+---+ | | |VRF+---+ | | | |VRF+---+ |
|+---+ | | |+---+ | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ |
|+---+ | |+---+ | |+---+ |
+------------+ +------------+ +------------+
| ^ | ^
| | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1)
Irrespective of the redundant G-sources being multi-homed or single-homed, if the tenant network has only one Broadcast Domain, e.g., BD1, the procedures of Section 5.2 still apply, only that routes do not include any SBD route target, i.e.,: SBD-RT, and all the procedures apply to Broadcast Domain BD1 only.¶
The same Security Considerations described in [I-D.ietf-bess-evpn-irb-mcast] are valid for this document.¶
From a security perspective, out of the two methods described in this document, the Warm Standby method is considered lighter in terms of control plane and therefore its impact is low on the processing 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 receivers.¶
IANA is requested to allocate a Bit in the Multicast Flags Extended Community to indicate that a given (*,G) or (S,G) in an S-PMSI A-D route is associated with an SFG (Single Flow Group).¶
The authors would like to thank Mankamana Mishra, Ali Sajassi and Greg Mirsky for their review and valuable comments.¶