rfc9856v2.txt | rfc9856.txt | |||
---|---|---|---|---|
skipping to change at line 373 ¶ | skipping to change at line 373 ¶ | |||
* For example, if PE1 uses "IR", it will forward (S1,G1) only to | * For example, if PE1 uses "IR", it will forward (S1,G1) only to | |||
downstream PEs that have issued a "SMET" route for (S1,G1), | downstream PEs that have issued a "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., AR or BIER), | * If PE1 uses a P-tunnel type other than IR (e.g., AR or 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 | (S1,G1). Downstream PEs, such as PE2 and PE3, will then join | |||
the 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) + | | |||
skipping to change at line 577 ¶ | skipping to change at line 577 ¶ | |||
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 AC. | discards all (*,G) or (S,G) packets received over its local AC. | |||
* 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 AC for | forwards (*,G) or (S,G) packets received on a single local AC for | |||
the SFG. If packets are received on multiple local ACs, the | the SFG. If packets are received on multiple local ACs, the | |||
Single Forwarder discards packets on all but one. The selection | Single Forwarder discards packets on all but one. The selection | |||
of the AC for forwarding is a local implementation detail. | of the AC 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 | |||
skipping to change at line 754 ¶ | skipping to change at line 756 ¶ | |||
* 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: MUST include the SFG | - Multicast Flags Extended Community: MUST include the 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 DF election defined in [RFC8584]. | election, using the DF election defined in [RFC8584]. | |||
* Advertises the route: | * Advertises the route: | |||
skipping to change at line 816 ¶ | skipping to change at line 817 ¶ | |||
capabilities, the tie-breaker is the lowest PE IP address | capabilities, the tie-breaker is the lowest PE IP address | |||
(as advertised in the Originator Address field of the | (as advertised in the Originator Address field of the | |||
S-PMSI A-D route). | S-PMSI A-D route). | |||
4. Reverse Path Forwarding Checks on the 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 ACs. | 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 AC. | 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 Sections 4.2 | Examples of the Warm Standby solution are provided in Sections 4.2 | |||
and 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 | |||
skipping to change at line 912 ¶ | skipping to change at line 913 ¶ | |||
* 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 [RFC9785], PE1 | * Assuming they use Preference-based Election [RFC9785], PE1 | |||
(with a higher preference) is elected as the Single Forwarder | (with a higher preference) 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 AC. | 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 AC. | 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. | |||
End of changes. 7 change blocks. | ||||
17 lines changed or deleted | 18 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |