Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9856 J. Kotalwar
Category: Standards Track S. Sathappan
ISSN: 2070-1721 Nokia
Z. Zhang
W. Lin
Juniper
September 2025
In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalable Layer 2 and Layer 3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate IP multicast traffic in the network, causing inefficiencies and increased overhead. This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate IP multicast traffic from redundant sources. The proposed mechanisms enhance the EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies.
イーサネット仮想プライベートネットワーク（EVPN）では、IPマルチキャストトラフィックレプリケーションと配信が、効率的でスケーラブルなレイヤー2およびレイヤー3サービスを可能にする上で重要な役割を果たします。一般的な展開シナリオには、高可用性と回復力を確保する冗長なマルチキャストソースが含まれます。ただし、冗長なソースの存在は、ネットワーク内のIPマルチキャストトラフィックを重複させる可能性があり、非効率性とオーバーヘッドの増加を引き起こす可能性があります。このドキュメントは、冗長なソースからの重複IPマルチキャストトラフィックの抑制を可能にするEVPNマルチキャスト手順への拡張機能を指定します。提案されたメカニズムは、高可用性を維持しながらマルチキャストトラフィックを効率的に提供するEVPNの能力を高めます。これらの拡張機能は、さまざまなEVPN展開シナリオに適用され、多様なネットワークトポロジ全体で一貫した予測可能な動作を確保するためのガイドラインを提供します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9856で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.2. Background on IP Multicast Delivery in EVPN Networks
1.2.1. Intra-Subnet IP Multicast Forwarding
1.2.2. Inter-Subnet IP Multicast Forwarding
1.3. Multi-Homed IP Multicast Sources in EVPN
1.4. The Need for Redundant IP Multicast Sources in EVPN
2. Solution Overview
2.1. Warm Standby Solution
2.2. Hot Standby Solution
2.3. Solution Selection
2.4. System Support
3. BGP EVPN Extensions
3.1. Single Flow Group Flag in the Multicast Flags Extended
Community
3.2. ESI Label Extended Community in S-PMSI A-D Routes
4. Warm Standby (WS) Solution for Redundant G-Sources
4.1. Specification
4.2. Warm Standby Example in an OISM Network
4.3. Warm Standby Example in a Single-BD Tenant Network
5. Hot Standby Solution for Redundant G-Sources
5.1. Specification
5.2. Extensions for the Advertisement of DCB Labels
5.3. Use of BFD in the HS Solution
5.4. Hot Standby Example in an OISM Network
5.4.1. Multi-Homed Redundant G-Sources
5.4.2. Single-Homed Redundant G-Sources
5.5. Hot Standby Example in a Single-BD Tenant Network
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Ethernet Virtual Private Networks (EVPNs) [RFC7432] support both intra-subnet and inter-subnet IP multicast forwarding. [RFC9251] outlines the procedures required to optimize the delivery of IP multicast flows when both sources and receivers are connected to the same EVPN Broadcast Domain. [RFC9625], on the other hand, defines the procedures for supporting inter-subnet IP multicast within a tenant network, where the IP multicast source and receivers of the same multicast flow are connected to different Broadcast Domains within the same tenant.
イーサネット仮想プライベートネットワーク（EVPNS）[RFC7432]は、サブネット内およびサブネット間の両方のIPマルチキャスト転送の両方をサポートしています。[RFC9251]は、ソースとレシーバーの両方が同じEVPNブロードキャストドメインに接続されている場合、IPマルチキャストフローの配信を最適化するために必要な手順の概要を説明します。一方、[RFC9625]は、同じマルチキャストフローのIPマルチキャストソースとレシーバーが同じテナント内の異なるブロードキャストドメインに接続されているテナントネットワーク内のサブネット間IPマルチキャストをサポートする手順を定義します。
However, [RFC9251], [RFC9625], and conventional IP multicast techniques do not provide a solution for scenarios where:
ただし、[RFC9251]、[RFC9625]、および従来のIPマルチキャスト技術は、次のシナリオのソリューションを提供しません。
1. A given multicast group carries multiple flows (i.e., multiple sources are active), and
1. 特定のマルチキャストグループには、複数のフロー（つまり、複数のソースがアクティブ）を搭載し、
2. Each receiver should receive only from one source.
2. 各レシーバーは、1つのソースからのみ受信する必要があります。
Existing multicast solutions typically assume that there are no redundant sources sending identical flows to the same IP multicast group. In cases where redundant sources do exist, the receiver application is expected to handle duplicate packets.
既存のマルチキャストソリューションは、通常、同じIPマルチキャストグループに同一のフローを送信する冗長なソースがないと想定しています。冗長なソースが存在する場合、レシーバーアプリケーションは重複したパケットを処理することが期待されます。
In conventional IP multicast networks, such as those running Protocol Independent Multicast (PIM) [RFC7761] or Multicast Virtual Private Network (MVPN) [RFC6513], a workaround is to configure all redundant sources with the same IP address. This approach ensures that each receiver gets only one flow because:
実行中のプロトコル独立マルチキャスト（PIM）[RFC7761]やマルチキャスト仮想プライベートネットワーク（MVPN）[RFC6513]などの従来のIPマルチキャストネットワークでは、同じIPアドレスですべての冗長ソースを構成することです。このアプローチにより、各レシーバーが1つのフローしか得られないことを保証します。
* The Rendezvous Point (RP) in the multicast network always creates the (S,G) state for each source.
* マルチキャストネットワークのランデブーポイント（RP）は、各ソースの（s、g）状態を常に作成します。
* The Last Hop Router (LHR) may also create the (S,G) state.
* 最後のホップルーター（LHR）は、（s、g）状態を作成する場合があります。
* 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 address, the resulting source-specific trees ensure that each LHR or RP resides on at most one tree.
* （s、g）状態は、流れをソースIPアドレスに根付いたソース固有のツリーに結合します。複数のソースが同じIPアドレスを共有すると、結果のソース固有のツリーは、各LHRまたはRPが最大1つのツリーに存在することを保証します。
This workaround, which often uses anycast addresses, is suitable for Warm Standby (WS) redundancy solutions (Section 4). However, it is not effective for Hot Standby (HS) redundancy scenarios (Section 5), and it introduces challenges when sources need to be reachable via IP unicast or when multiple sources with the same IP address are attached to the same Broadcast Domain. In scenarios where multiple multicast sources stream traffic to the same group using EVPN Optimized Inter-Subnet Multicast (OISM), there is not necessarily any (S,G) state created for the redundant sources. In such cases, the Last Hop Routers may only have a (*,G) state, and there may not be an RP router to create an (S,G) state.
多くの場合、Anycastアドレスを使用するこの回避策は、Warm Standby（WS）冗長ソリューションに適しています（セクション4）。ただし、Hot Standby（HS）冗長シナリオ（セクション5）には効果的ではなく、IPユニキャストを介してソースに到達可能にする必要がある場合、または同じIPアドレスを持つ複数のソースが同じブロードキャストドメインに添付されている場合に課題を導入します。複数のマルチキャストソースがEVPN最適化されたインターサブネットマルチキャスト（OISM）を使用して同じグループにトラフィックをストリーミングするシナリオでは、冗長なソース用に作成された（s、g）状態は必ずしもありません。そのような場合、最後のホップルーターは（*、g）状態のみを持つ場合があり、（s、g）状態を作成するRPルーターがない場合があります。
This document extends [RFC9251] and [RFC9625] to address scenarios where IP multicast source redundancy exists. Specifically, it defines procedures for EVPN Provider Edge (PE) devices/routers to ensure that receivers do not experience packet duplication when two or more sources send identical IP multicast flows into the tenant domain. These procedures are limited to the context of [RFC9251] and [RFC9625]; handling redundant sources in other multicast solutions is beyond the scope of this document.
このドキュメントは[RFC9251]および[RFC9625]を拡張して、IPマルチキャストソースの冗長性が存在するシナリオに対処します。具体的には、EVPNプロバイダーエッジ（PE）デバイス/ルーターの手順を定義して、2つ以上のソースが同一のIPマルチキャストフローをテナントドメインに送信する場合、受信機がパケットの重複を経験しないようにします。これらの手順は、[RFC9251]および[RFC9625]のコンテキストに限定されています。他のマルチキャストソリューションで冗長なソースを処理することは、このドキュメントの範囲を超えています。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
BD:
BD:
Broadcast Domain. An emulated Ethernet, such that two systems on the same BD will receive each other's link-local broadcasts. 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 or multiple BDs of the same tenant.
ブロードキャストドメイン。同じBD上の2つのシステムが互いのLink-Localブロードキャストを受信するように、エミュレートされたイーサネット。このドキュメントでは、「BD」とは、EVPN PE上のブロードキャストドメインのインスタンス化も指します。EVPN PEは、同じテナントの1つまたは複数のBDに接続できます。
BUM:
BUM:
Broadcast, Unknown Unicast, and Multicast traffic.
ブロードキャスト、不明なユニキャスト、およびマルチキャストトラフィック。
DF:
DF:
Designated Forwarder. As defined in [RFC7432], an Ethernet Segment (ES) may be multi-homed (attached to more than one PE). An ES may also contain multiple BDs of one or more EVIs. For each such EVI, one of the PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a given segment.
指定されたフォワーダー。[RFC7432]で定義されているように、イーサネットセグメント（ES）はマルチホーム（複数のPEに接続されています）を使用できます。ESには、1つ以上のEVIの複数のBDが含まれる場合があります。そのようなEVIそれぞれについて、セグメントに接続されたPEの1つは、そのセグメントのEVIのDFになります。BDは1つのEVIのみに属する可能性があるため、特定のセグメントについてBDのDFを明確に話すことができます。
Downstream PE:
下流のPE：
In this document, a downstream PE is referred to as the EVPN PE that is connected to the IP Multicast receivers and gets the IP Multicast flows from remote EVPN PEs.
このドキュメントでは、下流のPEは、IPマルチキャストレシーバーに接続され、リモートEVPN PESからIPマルチキャストフローを取得するEVPN PEと呼ばれます。
EVI:
EVI:
EVPN Instance.
EVPNインスタンス。
G-traffic:
G-トラフィック：
Any frame with an IP payload whose destination IP address is a multicast group G.
宛先IPアドレスがマルチキャストグループGであるIPペイロードを持つすべてのフレーム。
G-source:
Gソース：
Any system sourcing IP multicast traffic to group G.
グループGへのIPマルチキャストトラフィックを調達するシステム。
Hot Standby Redundancy:
ホットスタンバイ冗長性：
The multicast source redundancy procedure defined in this document, by which 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.
このドキュメントで定義されたマルチキャストソース冗長性手順。上流のPESが冗長なマルチキャストフローを下流のPEに転送し、下流のPESは、関心のある付属のレシーバーに1つのフローのみが転送されることを確認します。
IGMP:
IGMP：
Internet Group Management Protocol [RFC9776].
インターネットグループ管理プロトコル[RFC9776]。
I-PMSI:
i-pmsi：
Inclusive Multicast Tree or Inclusive Provider Multicast Service Interface. While defined in [RFC6513], in this document it is only applicable to EVPN and refers to the default multicast tree for a given BD. All the EVPN PEs that are attached to a specific BD belong to the I-PMSI for the BD. The I-PMSI trees are signaled by EVPN Inclusive Multicast Ethernet Tag (IMET) routes.
包括的マルチキャストツリーまたは包括的プロバイダーマルチキャストサービスインターフェイス。[RFC6513]で定義されていますが、このドキュメントではEVPNにのみ適用でき、特定のBDのデフォルトのマルチキャストツリーを参照しています。特定のBDに接続されているすべてのEVPN PEは、BDのI-PMSIに属します。I-PMSIツリーは、EVPN包括的マルチキャストイーサネットタグ（IMET）ルートによって信号を送られます。
IMET route:
IMETルート：
EVPN Inclusive Multicast Ethernet Tag route, as in [RFC7432].
[RFC7432]のように、EVPNインクルーシブマルチキャストイーサネットタグルート。
MLD:
MLD:
Multicast Listener Discovery [RFC9777].
マルチキャストリスナーディスカバリー[RFC9777]。
MVPN:
MVPN：
Multicast Virtual Private Networks, as in [RFC6513].
[RFC6513]のように、マルチキャスト仮想プライベートネットワーク。
OISM:
oism：
Optimized Inter-Subnet Multicast, as in [RFC9625].
[RFC9625]のように、最適化されたサブネット間マルチキャスト。
PE:
PE:
Provider Edge.
プロバイダーエッジ。
PIM:
PIM:
Protocol Independent Multicast, as in [RFC7761].
[RFC7761]のように、プロトコル独立したマルチキャスト。
P-tunnel:
Pトンネル：
The term "Provider tunnel" refers to the type of tree employed by an upstream EVPN PE to forward multicast traffic to downstream PEs. The P-tunnels supported in this document include Ingress Replication (IR), Assisted Replication (AR) [RFC9574], Bit Indexed Explicit Replication (BIER) [RFC8296], multicast Label Distribution Protocol (mLDP), and Point-to-Multipoint (P2MP) RSVP - Traffic Engineering (RSVP-TE) extensions.
「プロバイダートンネル」という用語は、上流のEVPN PEによって採用されているツリーのタイプを指し、マルチキャストトラフィックを下流のPEに転送します。このドキュメントでサポートされているPタンネルには、Ingress Replication（IR）、Assisted Replication（AR）[RFC9574]、ビットインデックス付き明示的複製（BIER）[RFC8296]、マルチキャストラベル分布プロトコル（MLDP）、およびポイントツーマルティポイント（P2MP）RSVP-トラフィック工学（RSVP-TE）が含まれます。
Redundant G-source:
冗長なGソース：
A host or router transmitting a Single Flow Group (SFG) within a tenant network, where multiple hosts or routers are also transmitting the same SFG. Redundant G-sources transmitting the same SFG should have distinct IP addresses; however, they may share the same IP address if located in different Broadcast Domains (BDs) within the same tenant network. For the purposes of this document, redundant G-sources are assumed to not exhibit "bursty" traffic behavior.
テナントネットワーク内で単一のフローグループ（SFG）を送信するホストまたはルーター。複数のホストまたはルーターも同じSFGを送信しています。同じSFGを送信する冗長なG-ソースには、異なるIPアドレスが必要です。ただし、同じテナントネットワーク内の異なるブロードキャストドメイン（BDS）にある場合、同じIPアドレスを共有する場合があります。このドキュメントの目的のために、冗長なG-ソースは、「破裂した」交通行動を示さないと想定されています。
S-ES and S-ESI:
S-ESおよびS-ESI：
Multicast Source Ethernet Segment and multicast Source Ethernet Segment Identifier. The ES and ESI associated to a G-source.
マルチキャストソースイーサネットセグメントとマルチキャストソースイーサネットセグメント識別子。Gソースに関連付けられたESとESI。
S-PMSI:
S-PMSI：
Selective Multicast Tree or Selective Provider Multicast Service Interface. As defined in [RFC6513], this term refers to a multicast tree to which only the PEs interested in a specific Broadcast Domain belong. In the context of this document, it is specific to EVPN. Two types of EVPN S-PMSIs are supported:
選択的なマルチキャストツリーまたは選択的プロバイダーマルチキャストサービスインターフェイス。[RFC6513]で定義されているように、この用語は、特定のブロードキャストドメインに関心のあるPEのみが属するマルチキャストツリーを指します。このドキュメントのコンテキストでは、EVPNに固有です。2種類のEVPN S-PMSIがサポートされています。
S-PMSIs with Auto-Discovery routes:
自動配置ルートを備えたS-PMSIS：
These S-PMSIs require the upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI A-D) routes, as described in [RFC9572]. Downstream PEs interested in the multicast traffic join the S-PMSI tree following the procedures specified in [RFC9572].
これらのS-PMSISには、[RFC9572]で説明されているように、S-PMSIオートディスコービリ（S-PMSI A-D）ルートを宣伝するために上流のPEが必要です。[RFC9572]で指定された手順に従って、マルチキャストトラフィックに関心のある下流のPEがS-PMSIツリーに加わります。
S-PMSIs without Auto-Discovery Routes:
自動配置ルートのないS-PMSIS：
These S-PMSIs do not require the advertisement of S-PMSI A-D routes. Instead, they rely on the forwarding information provided by IMET routes. Upstream PEs forward IP multicast flows only to downstream PEs that advertise Selective Multicast Ethernet Tag (SMET) routes for the specific flow. These S-PMSIs are supported exclusively with the following P-tunnel types: IR, AR, and BIER.
これらのS-PMSISは、S-PMSI A-Dルートの広告を必要としません。代わりに、IMETルートが提供する転送情報に依存しています。アップストリームPESフォワードIPマルチキャストフローは、特定のフローの選択的マルチキャストイーサネットタグ（SMET）ルートを宣伝する下流のPESにのみフローします。これらのS-PMSIは、IR、AR、およびビアの次のPトンネルタイプでのみサポートされています。
SFG:
SFG:
Single Flow Group. A multicast group that represents traffic containing a single flow. Multiple sources, which may have the same or different IP addresses, can transmit traffic for an SFG. An SFG can be represented in two forms:
シングルフローグループ。単一のフローを含むトラフィックを表すマルチキャストグループ。同じまたは異なるIPアドレスを持つ可能性のある複数のソースは、SFGのトラフィックを送信できます。SFGは2つの形式で表現できます。
(*,G):
（*、g）：
Indicates that any source transmitting multicast traffic to group G is considered a redundant G-source for the SFG.
グループGにマルチキャストトラフィックを送信するソースは、SFGの冗長なGソースと見なされることを示します。
(S,G):
（S、G）：
Indicates that S is a prefix of any length. In this representation, a source is deemed a redundant G-source for the SFG if its address matches the specified prefix S.
Sが任意の長さの接頭辞であることを示します。この表現では、ソースは、指定されたプレフィックスSと一致する場合、SFGの冗長なGソースと見なされます。
SMET route:
スメットルート：
Selective Multicast Ethernet Tag route, as in [RFC9251].
[RFC9251]のように、選択的マルチキャストイーサネットタグルート。
(S,G) and (*,G):
（s、g）および（*、g）：
Used to describe multicast packets or multicast state. "S" stands for Source (IP address of the multicast traffic), and "G" stands for the Group or multicast destination IP address of the group. An (S,G) multicast packet refers to an IP packet with source IP address "S" and destination IP address "G", and it is forwarded on a multicast router if there is a corresponding state for (S,G). A (*,G) multicast packet refers to an IP packet with "any" source IP address and a destination IP address "G", and it is forwarded on a multicast router based on the existence of the corresponding (*,G) state. The document uses variations of these terms. For example, (S1,G1) represents the multicast packets or multicast state for source IP address "S1" and group IP address "G1".
マルチキャストパケットまたはマルチキャスト状態を説明するために使用されます。「S」はソース（マルチキャストトラフィックのIPアドレス）の略で、「G」はグループまたはグループのマルチキャスト宛先IPアドレスの略です。AN（S、G）マルチキャストパケットは、ソースIPアドレス「S」と宛先IPアドレス「G」を持つIPパケットを指し、（S、G）の対応する状態がある場合、マルチキャストルーターに転送されます。a（*、g）マルチキャストパケットは、「任意の」ソースIPアドレスと宛先IPアドレス「G」を備えたIPパケットを指し、対応する（*、g）状態の存在に基づいてマルチキャストルーターに転送されます。ドキュメントでは、これらの用語のバリエーションを使用しています。たとえば、（S1、G1）は、ソースIPアドレス「S1」およびグループIPアドレス「G1」のマルチキャストパケットまたはマルチキャスト状態を表します。
Upstream PE:
上流のPE：
In this document, an upstream PE refers to either the EVPN PE that is directly connected to the IP multicast source or the PE closest to the source. The upstream PE receives IP multicast flows through local Attachment Circuits (ACs).
このドキュメントでは、上流のPEは、IPマルチキャストソースに直接接続されているEVPN PEまたはソースに最も近いPEを指します。上流のPEは、ローカルアタッチメントサーキット（ACS）を介してIPマルチキャストフローを受け取ります。
Warm Standby Redundancy:
温かいスタンバイ冗長性：
A multicast source redundancy mechanism defined in this document, wherein the upstream PEs connected to redundant sources within the same tenant ensure that only one source of a given flow transmits multicast traffic to the interested downstream PEs at any given time.
このドキュメントで定義されているマルチキャストソース冗長性メカニズム。同じテナント内の冗長なソースに接続された上流のPESが、特定のフローの1つのソースのみが、特定の時期に関心のあるダウンストリームPEにマルチキャストトラフィックを送信することを保証します。
This document also assumes familiarity with the terminology of [RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251], [RFC9625], [RFC9136], and [RFC9572].
この文書は、[RFC7432]、[RFC4364]、[RFC6513]、[RFC6514]、[RFC9251]、[RFC9625]、[RFC9136]、[RFC9136]、[RFC9572]の用語にも精通しています。
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. In an EVPN tenant domain, the multicast tree can be constructed where the source (S) and the receivers for the multicast group (G) are either connected to the same Broadcast Domain (BD) or to different Broadcast Domains. The former scenario is referred to as "Intra-subnet IP Multicast forwarding", while the latter is referred to as "Inter-subnet IP Multicast forwarding".
IPマルチキャストは、マルチキャストツリーに沿って、ソースからレシーバーのグループ（G）へのパケットの単一コピーの配信を促進します。EVPNテナントドメインでは、マルチキャストグループ（g）のソースとレシーバーが同じブロードキャストドメイン（BD）または異なるブロードキャストドメインに接続されている場合、マルチキャストツリーを構築できます。前のシナリオは「サブネット内IPマルチキャスト転送」と呼ばれ、後者は「Subnet IP Multicast Forwarding」と呼ばれます。
When the source S1 and the receivers interested in G1 are connected to the same Broadcast Domain, the EVPN network can deliver IP multicast traffic to the receivers using two different approaches, as illustrated in Figure 1:
G1に関心のあるソースS1と受信機が同じブロードキャストドメインに接続されている場合、EVPNネットワークは、図1に示すように、2つの異なるアプローチを使用してIPマルチキャストトラフィックを受信機に配信できます。
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- - -
Figure 1: Intra-Subnet IP Multicast
図1：サブネット内IPマルチキャスト
Model (a):
モデル（a）：
IP Multicast Delivery as BUM Traffic
BUMトラフィックとしてのIPマルチキャスト配信
The upstream PE sends the IP Multicast flows to all downstream PEs, even to PEs with non-interested receivers, such as, e.g., PE4 in Figure 1. To optimize this behavior, downstream PEs can snoop IGMP/MLD messages from receivers to build Layer 2 multicast state. For instance, PE4 could avoid forwarding (S1,G1) to R3, since R3 has not expressed interest in (S1,G1).
上流のPEは、図1のPE4など、IPマルチキャストフローをすべての下流のPESに送信します。たとえば、図1のPE4などの非関心のある受信機を使用します。たとえば、R3は（S1、G1）に関心を表明していないため、PE4は転送（S1、G1）をR3からR3に回避できます。
Model (b):
モデル（b）：
Optimized Delivery with S-PMSI
S-PMSIを使用した最適化された配信
Model (b) in Figure 1 uses a "Selective Provider Multicast Service Interface (S-PMSI)" to optimize the delivery of the (S1,G1) flow.
図1のモデル（b）は、「Selective Provider Multicast Service Interface（S-PMSI）」を使用して、（S1、G1）フローの提供を最適化します。
* For example, if PE1 uses "IR", it will forward (S1,G1) only to downstream PEs that have issued a "SMET" route for (S1,G1), such as PE2 and PE3.
* たとえば、PE1が「IR」を使用する場合、PE2やPE3などの（S1、G1）の「SMET」ルートを発行した下流のPESのみに（S1、G1）を転送します。
* 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 (S1,G1). Downstream PEs, such as PE2 and PE3, will then join the corresponding multicast tree to receive the flow.
* PE1がIR以外のPトンネルタイプ（ARまたはBIERなど）を使用している場合、PE1は（S1、G1）の「S-PMSIオートディスコーブリ（A-D）」ルートを宣伝します。PE2やPE3などの下流のPESが、対応するマルチキャストツリーを結合してフローを受け取ります。
Procedures for Model (b) are specified in [RFC9251] and [RFC9572].
モデル（b）の手順は、[RFC9251]および[RFC9572]で指定されています。
When the sources and receivers are connected to different BDs within the same tenant domain, the EVPN network can deliver IP multicast traffic using either Inclusive or Selective Multicast Trees, as illustrated in Figure 2 with models (a) and (b), respectively.
ソースとレシーバーが同じテナントドメイン内の異なるBDに接続されている場合、EVPNネットワークは、それぞれモデル（a）と（b）を使用して図2に示すように、包括的または選択的なマルチキャストツリーを使用してIPマルチキャストトラフィックを提供できます。
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- - -
Figure 2: Inter-Subnet IP Multicast
図2：インターサブネットIPマルチキャスト
As defined in [RFC9625], inter-subnet multicast forwarding in EVPN is 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 BD, the IP multicast flow is delivered to the Supplementary Broadcast Domain (SBD), as shown in Figure 2.
[RFC9625]で定義されているように、EVPNのサブネット間マルチキャスト転送は、ソースBDのコンテキスト内でIPマルチキャストフローが送信されるようにすることにより最適化されます。下流のPEがソースBDに接続されていない場合、図2に示すように、IPマルチキャストフローが補足放送ドメイン（SBD）に配信されます。
* Inclusive and Selective Multicast Trees
* 包括的で選択的なマルチキャストツリー
Model (a):
モデル（a）：
Inclusive Multicast Tree
包括的マルチキャストツリー
In this model, the Inclusive Multicast Tree for BD1 on PE1 delivers (S1,G1) to all downstream PEs, such as PE2, PE3, and PE4, in the context of the SBD. Each downstream PE then locally routes the flow to its ACs, ensuring delivery to interested receivers.
このモデルでは、PE1のBD1用の包括的なマルチキャストツリーは、SBDのコンテキストでPE2、PE3、PE4などのすべての下流PEに（S1、G1）を配信します。その後、各下流のPEは、流れをACSに局所的にルーティングし、関心のあるレシーバーへの配信を保証します。
Model (b):
モデル（b）：
Selective Multicast Tree
選択的なマルチキャストツリー
In this model, PE1 optimizes forwarding by delivering (S1,G1) only to downstream PEs that explicitly indicate interest in the flow via SMET routes. If the P-tunnel type is "IR", "AR", or "BIER", PE1 does not need to advertise an S-PMSI A-D route. Downstream PEs join the multicast tree based on the SMET routes advertised for (S1,G1).
このモデルでは、PE1は、SMETルートを介したフローへの関心を明示的に示す下流PESにのみ（S1、G1）を配信することにより、転送を最適化します。Pトンネルタイプが「IR」、「AR」、または「BIER」の場合、PE1はS-PMSI A-Dルートを宣伝する必要はありません。下流のPEは、（S1、G1）に宣伝されているSMETルートに基づいて、マルチキャストツリーに結合します。
* Advantages of [RFC9625]
* [RFC9625]の利点
[RFC9625] extends the procedures defined in [RFC9251] to support both intra- and inter-subnet multicast forwarding for EVPN. It ensures that every upstream PE attached to a source is aware of all downstream PEs within the same tenant domain that have interest in specific flows. This is achieved through the advertisement of SMET routes with the SBD Route Target, which are imported by all upstream PEs.
[RFC9625]は、[RFC9251]で定義されている手順を拡張して、EVPNのサブネット内およびインタースブネット間のマルチキャスト転送の両方をサポートします。ソースに接続されたすべての上流のPEが、特定のフローに関心のある同じテナントドメイン内のすべての下流のPEを認識していることを保証します。これは、SBDルートターゲットを備えたSMETルートの広告を通じて達成されます。これは、すべての上流のPESによってインポートされます。
* Elimination of Complexity
* 複雑さの排除
The inter-subnet multicast mechanism defined in [RFC9625] eliminates the need for: Rendezvous Points (RPs), shared trees, upstream multicast hop selection, or other complex conventional multicast routing techniques.
[RFC9625]で定義されたサブネット間マルチキャストメカニズムは、ランデブーポイント（RPS）、共有ツリー、上流のマルチキャストホップ選択、またはその他の複雑な従来のマルチキャストルーティング技術の必要性を排除します。
By leveraging the EVPN framework, inter-subnet multicast forwarding achieves efficient delivery without introducing unnecessary overhead or dependencies on classic IP multicast protocols.
EVPNフレームワークを活用することにより、Subnet Inter-Subnetマルチキャスト転送は、クラシックIPマルチキャストプロトコルに不必要なオーバーヘッドまたは依存関係を導入することなく、効率的な配信を実現します。
Unlike conventional multicast routing technologies, multi-homed PEs connected to the same source do not create IP multicast packet duplication when utilizing a multi-homed ES. Figure 3 illustrates this scenario, where two multi-homed PEs (PE1 and PE2) are attached to the same source S1. The source S1 is connected via a Layer 2 switch (SW1) to an all-active ES (ES-1), with a Link Aggregation Group (LAG) extending to PE1 and PE2.
従来のマルチキャストルーティングテクノロジーとは異なり、同じソースに接続されたマルチホームPESは、マルチホームESを利用するときにIPマルチキャストパケットの複製を作成しません。図3は、このシナリオを示しています。ここでは、2つのマルチホームPE（PE1とPE2）が同じソースS1に接続されています。ソースS1は、レイヤー2スイッチ（SW1）を介してオールアクティブES（ES-1）に接続され、リンク集約グループ（LAG）がPE1およびPE2に拡張されます。
S1
|
v
+-----+
| SW1 |
+-----+
+---- | |
(S1,G1)| +----+ +----+
IGMP/MLD | | 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/MLD | v v | IGMP/MLD
J(*,G1) | R2 R3 | J(S1,G1)
Figure 3: All-Active Multi-Homing and OISM
図3：オールアクティブなマルチホミングとOISM
When S1 transmits the (S1,G1) flow, SW1 selects a single link within the all-active ES to forward the flow, as per [RFC7432]. In this example, assuming PE1 is the receiving PE for BD1, the multicast flow is forwarded once BD1 establishes multicast state for (S1,G1) or (*,G1). In Figure 3:
S1が（S1、G1）フローを送信すると、SW1は[RFC7432]に従って、すべて活性ES内の単一のリンクを選択してフローを転送します。この例では、BD1の受信PEであると仮定すると、BD1が（S1、G1）または（*、G1）のマルチキャスト状態を確立すると、マルチキャストフローが転送されます。図3：
* Receiver R1 receives (S1,G1) directly via the IRB (Integrated Routing and Bridging) interface, defined in [RFC9135], following the procedures in [RFC9625].
* [RFC9625]の手順に従って、[RFC9135]で定義されているIRB（統合ルーティングとブリッジング）インターフェイスを介して、受信機R1は（S1、G1）を直接受信します。
* Receivers R2 and R3, upon issuing IGMP/MLD reports, trigger PE3 to advertise an SMET (*,G1) route. This creates multicast state in 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 in [RFC9625].
* IGMP/MLDレポートを発行すると、Receivers R2およびR3は、SMET（*、G1）ルートを宣伝するためにPE3をトリガーします。これにより、PE1のBD1にマルチキャスト状態が作成され、PE1がマルチキャストフローをPE3のSBDに転送できます。その後、PE3は[RFC9625]で定義されているように、R2とR3に流れを届けます。
Requirements for Multi-Homed IP Multicast Sources:
マルチホームIPマルチキャストソースの要件：
* When IP multicast source multi-homing is needed, EVPN multi-homed ESes MUST be used.
* IPマルチキャストソースマルチホミングが必要な場合、EVPNマルチホームESEを使用する必要があります。
* EVPN multi-homing ensures that only one upstream PE forwards a given multicast flow at a time, preventing packet duplication at downstream PEs.
* EVPNマルチホミングは、1つの上流のPEのみが特定のマルチキャストフローを一度に前進させることを保証し、下流のPESでのパケットの重複を防ぎます。
* The SMET route for a multicast flow ensures that all upstream PEs in the multi-homed ES maintain state for the flow. This allows for immediate failover, as the backup PE can seamlessly take over forwarding in case of an upstream PE failure.
* マルチキャストフローのSMETルートは、マルチホームESのすべての上流PEが流れの状態を維持することを保証します。これにより、バックアップPEが上流のPE障害の場合にシームレスに転送を引き継ぐことができるため、即時フェールオーバーが可能になります。
This document assumes that multi-homed PEs connected to the same source always utilize multi-homed ESes.
このドキュメントは、同じソースに接続されたマルチホームPESが常にマルチホームESEを利用することを前提としています。
While multi-homing PEs to the same IP multicast G-source provides a certain level of resiliency, multicast applications are often critical in operator networks, necessitating a higher level of redundancy. This document assumes the following:
同じIP IPマルチキャストGソースへのマルチホーミングPEは、一定のレベルの復元力を提供しますが、多くの場合、オペレーターネットワークでマルチキャストアプリケーションが重要であるため、より高いレベルの冗長性が必要です。このドキュメントでは、次のことを想定しています。
a. Redundant G-sources: Redundant G-sources for an SFG may exist within the EVPN tenant network. A redundant G-source is defined as a host or router transmitting an SFG stream in a tenant network where another host or router is also sending traffic to the same SFG.
a. 冗長なG-ソース：SFGの冗長なG-ソースは、EVPNテナントネットワーク内に存在する可能性があります。冗長なGソースは、別のホストまたはルーターが同じSFGにトラフィックを送信しているテナントネットワークでSFGストリームを送信するホストまたはルーターとして定義されます。
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 restrictions on the locations of receiver systems within the tenant.
b. G-Sourceの配置：冗長なG-ソースは、同じBDまたはテナントネットワークの異なるBDに存在する場合があります。テナント内のレシーバーシステムの場所に制限がないはずです。
c. G-source attachment to EVPN PEs: Redundant G-sources may be either single-homed to a single EVPN PE or multi-homed to multiple EVPN PEs.
c. eVPN PESへのGソースのアタッチメント：冗長なG-ソースは、単一のEVPN PEに単一ホーム化されているか、複数のEVPN PEにマルチホームされている場合があります。
d. Packet duplication avoidance: The EVPN PEs must ensure that receiver systems do not experience duplicate packets for the same SFG.
d. パケットの複製回避：EVPN PESは、レシーバーシステムが同じSFGの重複パケットを経験しないようにする必要があります。
This framework ensures that EVPN networks can effectively support redundant multicast sources while maintaining high reliability and operational efficiency.
このフレームワークにより、EVPNネットワークは、高い信頼性と運用効率を維持しながら、冗長なマルチキャストソースを効果的にサポートできるようになります。
An SFG can be represented as (*,G) if any source transmitting multicast traffic to group G is considered a redundant G-source. Alternatively, this document allows an SFG to be represented as (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 its address falls within the specified prefix. In the remainder of this document, some examples use (*,G) state for brevity. Wherever an SFG is represented as (*,G), it should be understood as being 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.
SFGは、グループGにマルチキャストトラフィックを送信するソースが冗長なGソースと見なされる場合（*、g）として表現できます。あるいは、このドキュメントでは、SFGを（s、g）として表すことができます。ソースIPアドレスsは変数長のプレフィックスです。この場合、ソースは、そのアドレスが指定されたプレフィックス内に該当する場合、SFGの冗長なGソースと見なされます。このドキュメントの残りの部分では、いくつかの例は、簡潔にするために（*、g）状態を使用しています。SFGが（*、g）として表される場合は、（s、g）と交換可能であると理解する必要があります。このドキュメントでは、S-PMSI A-Dルートを介したソース広告での可変長プレフィックスの使用は、冗長なG-ソースの特定のアプリケーションに対してのみ許可されています。
This document describes two solutions for handling redundant G-sources:
このドキュメントでは、冗長なG-ソースを処理するための2つのソリューションについて説明します。
* Warm Standby Solution
* 温かいスタンバイソリューション
* Hot Standby Solution
* ホットスタンバイソリューション
The Warm Standby solution is an upstream PE-based solution, where downstream PEs do not participate in the procedures. In this solution, all upstream PEs connected to redundant G-sources for an SFG (*,G) or (S,G) elect a "Single Forwarder (SF)" among themselves. After the Single Forwarder is elected, the upstream PEs apply Reverse Path Forwarding checks to the multicast state for the SFG:
温かいスタンバイソリューションは、上流のPEベースのソリューションであり、下流のPEが手順に参加しません。このソリューションでは、SFG（*、g）または（s、g）の冗長なG-ソースに接続されたすべての上流のPESは、それ自体が「単一転送（SF）」を選択します。単一のフォワーダーが選出された後、上流のPESは、SFGのマルチキャスト状態に逆パス転送チェックを適用します。
* Non-Single Forwarder (Non-SF) Behavior: A Non-SF upstream PE discards all (*,G) or (S,G) packets received over its local AC.
* 非シングルフォワーダー（非SF）動作：非SF上流のPEは、ローカルACで受信したすべて（*、g）または（s、g）パケットを破棄します。
* Single Forwarder Behavior: The Single Forwarder accepts and forwards (*,G) or (S,G) packets received on a single local AC for the SFG. If packets are received on multiple local ACs, the Single Forwarder discards packets on all but one. The selection of the AC for forwarding is a local implementation detail.
* 単一のフォワーダーの動作：単一のフォワーダーは、SFGの単一のローカルACで受信した（*、g）または（s、g）パケットを受け入れて（s、g）パケットを受け入れます。複数のローカルACSでパケットが受信された場合、単一のフォワーダーは1つを除くすべてのパケットを破棄します。転送用のACの選択は、ローカルの実装の詳細です。
In the event of a failure of the Single Forwarder, a new Single Forwarder is elected among the upstream PEs. This election process requires BGP extensions on existing EVPN routes, which are detailed in Sections 3 and 4.
単一のフォワーダーが失敗した場合、上流のPESの中で新しい単一のフォワーダーが選出されます。この選挙プロセスでは、既存のEVPNルートのBGP拡張機能が必要です。これは、セクション3および4で詳述されています。
The Hot Standby solution relies on downstream PEs to prevent duplication of SFG packets. Upstream PEs, aware of locally connected G-sources, append a unique ESI label to multicast packets for each SFG. Downstream PEs receive SFG packets from all upstream PEs attached to redundant G-sources and avoid duplication by performing a Reverse Path Forwarding check on the (*,G) state for the SFG:
ホットスタンバイソリューションは、SFGパケットの重複を防ぐために、下流のPESに依存しています。局所的に接続されたG-ソースを認識しているアップストリームPEは、各SFGのマルチキャストパケットに一意のESIラベルを追加します。下流のPEは、冗長なG-ソースに接続されたすべての上流のPEからSFGパケットを受け取り、SFGの（*、g）状態で逆パス転送チェックを実行することにより、重複を避けます。
* Packet Filtering: A downstream PE discards (*,G) packets received from the "wrong G-source."
* パケットフィルタリング：「間違ったGソース」から受け取った下流のPE破棄（*、g）パケット。
* Wrong G-source Identification: The "wrong G-source" is identified using an ESI label that differs from the ESI label associated with the selected G-source.
* 間違ったGソースの識別：「間違ったG-ソース」は、選択したGソースに関連付けられたESIラベルとは異なるESIラベルを使用して識別されます。
* ESI Label Usage: In this solution, the ESI label is used for "ingress filtering" at the downstream PE, rather than for "egress filtering" as described in [RFC7432]. In [RFC7432], the ESI label indicates which egress ACs must be excluded when forwarding BUM traffic. Here, the ESI label identifies ingress traffic that should be discarded by the downstream PE.
* ESIラベルの使用法：このソリューションでは、ESIラベルは、[RFC7432]で説明されている「出口フィルタリング」ではなく、下流のPEでの「イングレスフィルタリング」に使用されます。[RFC7432]では、ESIラベルは、バムトラフィックを転送するときにどの出力ACを除外する必要があるかを示します。ここで、ESIラベルは、下流のPEによって破棄されるべき侵入トラフィックを識別します。
Control plane and data plane extensions to [RFC7432] are required to support ESI labels for SFGs forwarded by upstream PEs. Upon failure of the selected G-source, the downstream PE switches to a different G-source and updates its Reverse Path Forwarding check for the (*,G) state. These extensions and procedures are described in Sections 3 and 5.
[RFC7432]へのコントロールプレーンおよびデータプレーンの拡張は、上流のPESによって転送されるSFGのESIラベルをサポートする必要があります。選択したGソースが故障すると、下流のPEは別のGソースに切り替え、（*、g）状態の逆パス転送チェックを更新します。これらの拡張と手順については、セクション3および5で説明します。
Operators should select a solution based on their specific requirements:
オペレーターは、特定の要件に基づいてソリューションを選択する必要があります。
* The Warm Standby solution is more bandwidth-efficient but incurs longer failover times in the event of a G-source or upstream PE failure. Additionally, only the upstream PEs connected to redundant G-sources for the same SFG need to support the new procedures in the Warm Standby solution.
* 温かいスタンバイソリューションは、より帯域幅効率が高くなりますが、Gソースまたは上流のPE障害が発生した場合には、より長いフェールオーバー時間が発生します。さらに、同じSFGの冗長なG-ソースに接続された上流のPEのみが、温かいスタンバイソリューションで新しい手順をサポートする必要があります。
* The Hot Standby solution is recommended for scenarios requiring fast failover times, provided that the additional bandwidth consumption (due to multiple transmissions of SFG packets to downstream PEs) is acceptable.
* 追加の帯域幅消費量（SFGパケットの複数の送信による下流のPESのため）が許容される場合、速いフェイルオーバー時間を必要とするシナリオには、ホットスタンバイソリューションが推奨されます。
This document does not mandate support for both solutions on a single system. If one solution is implemented, support for the other is OPTIONAL.
このドキュメントは、単一のシステム上の両方のソリューションのサポートを義務付けていません。1つのソリューションが実装されている場合、他のソリューションのサポートはオプションです。
This document introduces the following BGP EVPN extensions:
このドキュメントでは、次のBGP EVPN拡張機能を紹介します。
A new Single Flow Group (SFG) flag is defined within the Multicast Flags Extended Community. This flag has been registered as bit 4 in 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 Flow Group information in the BGP EVPN Network Layer Reachability Information (NLRI).
新しいシングルフローグループ（SFG）フラグは、マルチキャストフラグ拡張コミュニティ内で定義されています。このフラグは、「マルチキャストフラグ拡張コミュニティ」レジストリにビット4として登録されています（表1を参照）。SFGフラグは、BGP EVPNネットワークレイヤーリーチビリティ情報（NLRI）の単一フローグループ情報を運ぶ（*、g）または（s、g）を運ぶs-pmsi a-dルートで設定されています。
The Hot Standby solution requires the advertisement of one or more ESI Label Extended Communities [RFC7432] alongside the S-PMSI A-D routes. These extended communities encode the ESI values associated with an S-PMSI A-D (*,G) or (S,G) route that advertises the presence of a Single Flow Group.
ホットスタンバイソリューションでは、S-PMSI A-Dルートとともに、1つ以上のESIラベル拡張コミュニティ[RFC7432]の広告が必要です。これらの拡張されたコミュニティは、単一のフローグループの存在を宣伝するS-PMSI A-D（*、G）または（S、G）ルートに関連付けられたESI値をエンコードします。
Key considerations include:
重要な考慮事項は次のとおりです。
1. When advertised with the S-PMSI A-D routes, only the ESI label value in the extended community is relevant to the procedures defined in this document.
1. S-PMSI A-Dルートで宣伝されると、拡張コミュニティのESIラベル値のみが、このドキュメントで定義されている手順に関連しています。
2. The Flags field within the extended community MUST be set to "0x00" on transmission and MUST be ignored on reception.
2. 拡張コミュニティ内のフラグフィールドは、送信時に「0x00」に設定する必要があり、レセプションでは無視する必要があります。
[RFC7432] specifies the use of the ESI Label Extended Community in conjunction with the A-D per ES route. This document extends the applicability of the ESI Label Extended Community by allowing its inclusion multiple times (with different ESI label values) alongside the EVPN S-PMSI A-D route. These extensions enable the precise encoding and advertisement of SFG-related information, facilitating efficient multicast traffic handling in EVPN networks.
[RFC7432]は、A-Dあたりのルートと併せてESIラベル拡張コミュニティの使用を指定します。このドキュメントは、EVPN S-PMSI A-Dルートとともに複数回（異なるESIラベル値を持つ）包含を許可することにより、ESIラベル拡張コミュニティの適用性を拡張します。これらの拡張機能により、SFG関連情報の正確なエンコードと広告が可能になり、EVPNネットワークでの効率的なマルチキャストトラフィックハンドリングが促進されます。
This section specifies the Warm Standby solution for handling redundant multicast sources (G-sources). Note that while the examples use IPv4 addresses, the solution supports both IPv4 and IPv6 sources.
このセクションでは、冗長なマルチキャストソース（G-Sources）を処理するための温かいスタンバイソリューションを指定します。例ではIPv4アドレスを使用していますが、ソリューションはIPv4とIPv6の両方のソースをサポートしていることに注意してください。
The Warm Standby solution follows these general procedures:
温かいスタンバイソリューションは、これらの一般的な手順に従います。
1. Configuration of the upstream PEs
1. 上流のPEの構成
Upstream PEs, potentially connected to redundant G-sources, are configured to recognize:
上流のPESは、冗長なG-ソースに潜在的に接続されており、認識するように構成されています。
* The multicast groups that carry an SFG in the tenant domain.
* テナントドメインでSFGを運ぶマルチキャストグループ。
* The local Broadcast Domains that may host redundant G-sources
* 冗長なG-ソースをホストする可能性のあるローカルブロードキャストドメイン
The SFG configuration applies to either "any" source, i.e., (*) or to a specific "source prefix" (e.g., "192.0.2.0/30" or "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 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, sources 2001:db8::1 or 2001:db8::2 are considered redundant G-sources for the SFG, but 2001:db8:1::1 is not.
SFG構成は、「任意の」ソース、つまり（*）または特定の「ソースプレフィックス」（例：「192.0.2.0/30」または「2001：db8 ::/120 "）のいずれかに適用されます。たとえば、IPv4プレフィックスが192.0.2.0/30の場合、ソース192.0.2.1および192.0.2.2のソースはSFGの冗長なGソースと見なされますが、192.0.2.10はそうではありません。IPv6の別の例では、プレフィックスが2001年の場合：db8 ::/120、Sources 2001：db8 :: 1または2001：db8 :: 2はsfgの冗長なg-sourcesと見なされますが、2001年：db8：1 :: 1はそうではありません。
Example Configuration (Figure 4):
構成の例（図4）：
* PE1 is configured to recognize G1 as an SFG for any source, with potential redundant G-sources attached to BD1 and BD2.
* PE1は、G1をあらゆるソースのSFGとして認識するように構成されており、BD1およびBD2に潜在的な冗長なGソースを取り付けています。
* Alternatively, PE1 may recognize G1 as an SFG for sources within 192.0.2.0/30 (or 2001:db8::/120), with redundant G-sources in BD1 and BD2.
* あるいは、PE1は、G1を192.0.2.0/30（または2001年：DB8 ::/120）以内のソースのSFGとして認識し、BD1およびBD2に冗長なG-ソースを使用します。
2. Signaling the location of a G-source for an SFG
2. SFGのGソースの位置を通知します
Upon receiving the first IP multicast packet for a configured SFG on a Broadcast Domain, an upstream PE (e.g., PE1):
ブロードキャストドメインで構成されたSFG用の最初のIPマルチキャストパケットを受信すると、上流のPE（例：PE1）：
* MUST advertise an S-PMSI A-D route for the SFG:
* SFGのS-PMSI A-Dルートを宣伝する必要があります。
- An (*,G) route if the SFG is configured for any source.
- SFGが任意のソースに対して構成されている場合、（*、g）ルート。
- An (S,G) route (where S can have any prefix length) if the SFG is configured for a source prefix.
- SFGがソースプレフィックス用に構成されている場合、（s、g）ルート（sは任意のプレフィックス長を持つことができます）。
* MUST include the following attributes in the S-PMSI A-D route:
* S-PMSI A-Dルートに次の属性を含める必要があります。
- Route Targets (RTs): The Broadcast Domain Route Target (BD-RT) of the BD receiving the traffic and, if applicable, the Supplementary Broadcast Domain Route Target (SBD-RT), which is needed so that the route is imported by all PEs attached to the tenant domain in an OISM solution.
- ルートターゲット（RTS）：トラフィックを受信するBDのブロードキャストドメインルートターゲット（BD-RT）、および該当する場合、補足放送ドメインルートターゲット（SBD-RT）。
- Multicast Flags Extended Community: MUST include the SFG flag to indicate that the route conveys an SFG.
- マルチキャストフラグ拡張コミュニティ：ルートがSFGを伝えることを示すために、SFGフラグを含める必要があります。
- Designated Forwarder Election Extended Community: Specifies the algorithm and preferences for the Single Forwarder election, using the DF election defined in [RFC8584].
- 指定されたフォワーダー選挙拡張コミュニティ：[RFC8584]で定義されているDF選挙を使用して、単一のフォワーダー選挙のアルゴリズムと選好を指定します。
* Advertises the route:
* ルートを宣伝します：
- Without a PMSI Tunnel Attribute if using IR, AR, or BIER.
- IR、AR、またはビアを使用する場合、PMSIトンネル属性なし。
- With a PMSI Tunnel Attribute for other tunnel types.
- 他のトンネルタイプのPMSIトンネル属性を備えています。
* MUST withdraw the S-PMSI A-D route when the SFG traffic ceases. A timer is RECOMMENDED to detect inactivity and trigger route withdrawal.
* SFGトラフィックが停止した場合、S-PMSI A-Dルートを撤回する必要があります。非アクティブを検出し、ルートの引き出しをトリガーするためにタイマーをお勧めします。
3. Single Forwarder Election on the upstream PEs
3. 上流のPESでの単一のフォワーダー選挙
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 based on the Designated Forwarder Election Extended Community.
上流のPEがリモートPEから同じSFGの1つまたは複数のS-PMSI A-Dルートを受け取った場合、指定されたフォワーダー選挙拡張コミュニティに基づいて単一のフォワーダー選挙を実行します。
* Two routes are considered part of the same SFG if they are advertised for the same tenant and match in the following fields:
* 同じテナントに宣伝され、次のフィールドで一致する場合、2つのルートは同じSFGの一部と見なされます。
- Multicast Source Length
- マルチキャストソースの長さ
- Multicast Source
- マルチキャストソース
- Multicast Group Length
- マルチキャストグループ長
- Multicast Group
- マルチキャストグループ
* Election Rules:
* 選挙規則：
1. A consistent DF Election Algorithm MUST be used across all upstream PEs for the Single Forwarder election. In OISM networks, the Default Designated Forwarder Election Algorithm MUST NOT be used if redundant G-sources are attached to Broadcast Domains with different Ethernet Tags.
1. 単一のフォワーダー選挙では、すべての上流のPEで一貫したDF選挙アルゴリズムを使用する必要があります。OISMネットワークでは、異なるイーサネットタグを持つブロードキャストドメインに冗長なGソースが添付されている場合、デフォルトの指定されたフォワーダー選挙アルゴリズムを使用しないでください。
2. In case of a mismatch in the DF Election Algorithm or capabilities, the tie-breaker is the lowest PE IP address (as advertised in the Originator Address field of the S-PMSI A-D route).
2. DF選挙アルゴリズムまたは機能の不一致の場合、タイブレーカーは最低のPE IPアドレスです（S-PMSI A-Dルートのオリジネーターアドレスフィールドで宣伝されています）。
4. Reverse Path Forwarding Checks on the Upstream PEs
4. 上流のPESの逆パス転送チェック
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 Forwarder election result:
SFGのローカルGソースを備えたすべてのPESは、単一のフォワーダー選挙結果に基づいて（*、g）または（s、g）状態に逆パス転送チェックを適用します。
1. Non-SF PEs: MUST discard all (*,G) or (S,G) packets received on local ACs.
1. 非SF PES：ローカルACSで受信したすべての（*、g）または（s、g）パケットを破棄する必要があります。
2. Single Forwarder PEs: MUST forward (*,G) or (S,G) packets received on one (and only one) local AC.
2. 単一のフォワーダーPES：1つ（*、g）または（s、g）パケットを1つ（および1つのみ）のローカルACで受信する必要があります。
Key Features of the Warm Standby Solution:
温かいスタンバイソリューションの主要な機能：
* The solution ensures redundancy for SFGs without requiring upgrades to downstream PEs (where no redundant G-sources are connected).
* このソリューションは、下流のPES（冗長なGソースが接続されていない場合）へのアップグレードを必要とせずにSFGの冗長性を保証します。
* Existing procedures for Non-SFG G-sources remain unchanged.
* 非SFG G-ソースの既存の手順は変更されていません。
* Redundant G-sources can be either single-homed or multi-homed. Multi-homing does not alter the above procedures.
* 冗長なG-ソースは、シングルホームまたはマルチホームのいずれかです。マルチホミングは上記の手順を変更しません。
Examples of the Warm Standby solution are provided in Sections 4.2 and 4.3.
温かいスタンバイソリューションの例は、セクション4.2および4.3に記載されています。
Figure 4 illustrates an example where S1 and S2 are redundant G-sources for the Single Flow Group (*,G1).
図4は、S1とS2が単一のフローグループ（*、G1）の冗長なGソースである例を示しています。
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/MLD | | IGMP/MLD
R1 | J(*,G1) R3| J(*,G1)
Figure 4: Warm Standby Solution for Redundant G-Sources
図4：冗長なG-ソースの温かいスタンバイソリューション
The Warm Standby procedure is as follows:
温かいスタンバイ手順は次のとおりです。
1. Configuration of the upstream PEs (PE1 and PE2)
1. 上流のPES（PE1およびPE2）の構成
* PE1 and PE2 are configured to recognize G1 as a Single Flow Group for any source.
* PE1とPE2は、G1をあらゆるソースの単一のフローグループとして認識するように構成されています。
* Redundant G-sources for G1 may be attached to BD1 (for PE1) and BD2 (for PE2).
* G1用の冗長G-Sourcesは、BD1（PE1の場合）およびBD2（PE2の場合）に取り付けられます。
2. Signaling the location of S1 and S2 for (*,G1)
2. （*、g1）のS1とS2の位置を信号する
Upon receiving traffic for G1 on a local AC:
ローカルACでG1のトラフィックを受信すると：
* PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including:
* PE1とPE2は、以下を含む（*、G1）のS-PMSI A-Dルートを発生します。
- the SBD-RT,
- SBD-RT、
- the Designated Forwarder Election Extended Community, and
- 指定されたフォワーダー選挙はコミュニティを拡張しました
- the SFG flag in the Multicast Flags Extended Community.
- マルチキャストフラグの拡張コミュニティのSFGフラグ。
* These routes indicate the presence of a Single Flow Group.
* これらのルートは、単一のフローグループの存在を示しています。
3. Single Forwarder Election
3. 単一のフォワーダー選挙
* Based on the Designated Forwarder Election Extended Community, PE1 and PE2 perform Single Forwarder election.
* 指定されたフォワーダー選挙拡張コミュニティに基づいて、PE1とPE2は単一のフォワーダー選挙を行います。
* Assuming they use Preference-based Election [RFC9785], PE1 (with a higher preference) is elected as the Single Forwarder for (*,G1).
* 優先ベースの選挙[RFC9785]を使用していると仮定すると、PE1（より高い選好を伴う）が（*、G1）の単一のフォワーダーとして選出されます。
4. Reverse Path Forwarding check on the PEs attached to a redundant G-source
4. 冗長なGソースに接続されたPESの逆パス転送チェック
a. Non-SF Behavior: PE2 discards all (*,G1) packets received on its local AC.
a. 非SF動作：PE2は、ローカルACで受信したすべての（*、G1）パケットを破棄します。
b. Single Forwarder Behavior: PE1 forwards (*,G1) packets received on one (and only one) local AC.
b. 単一のフォワーダーの動作：PE1フォワード（*、G1）パケットは、1つの（および1つのみ）ローカルACで受信しました。
The outcome:
結果：
* Upon receiving IGMP/MLD reports for (*,G1) or (S,G1), downstream PEs (PE3 and PE5) issue SMET routes to pull the multicast Single Flow Group traffic from PE1 only.
* （*、G1）または（S、G1）のIGMP/MLDレポートを受信すると、下流のPES（PE3およびPE5）がSMETルートを発行して、PE1からのみマルチキャストシングルフローグループトラフィックをプルします。
* In the event of a failure of S1, the AC connected to S1, or PE1 itself, the S-PMSI A-D route for (*,G1) is withdrawn by PE1.
* S1、S1またはPE1自体に接続されたACの障害が発生した場合、（*、G1）のS-PMSI A-DルートがPE1によって引き出されます。
* As a result, PE2 is promoted to Single Forwarder, ensuring continued delivery of (*,G1) traffic.
* その結果、PE2は単一のフォワーダーに昇格し、（*、G1）トラフィックの継続的な配信を保証します。
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 and receivers are connected to the same BD1, and there is no SBD.
図5は、S1とS2が単一のフローグループ（*、G1）の冗長なGソースである例を示しています。この場合、すべてのG-ソースと受信機は同じBD1に接続されており、SBDはありません。
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/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1)
Figure 5: WS Solution for Redundant G-Sources in the Same BD
図5：同じBDでの冗長なG-ソースのWSソリューション
The procedures for the Warm Standby solution in this example are identical to those described in Section 4.2, with the following distinction:
この例の温かいスタンバイソリューションの手順は、セクション4.2に記載されているものと同一であり、次の区別があります。
* Signaling the S-PMSI A-D Routes
* S-PMSI A-Dルートの信号
- Upon receiving traffic for the Single Flow Group (*,G1), PE1 and PE2 advertise S-PMSI A-D routes.
- 単一のフローグループ（*、G1）のトラフィックを受信すると、PE1およびPE2はS-PMSI A-Dルートを宣伝します。
- These routes include only the BD1-RT (Broadcast Domain 1 Route Target) as there is no SBD in this scenario.
- これらのルートには、このシナリオにはSBDがないため、BD1-RT（ブロードキャストドメイン1ルートターゲット）のみが含まれます。
This example represents a specific sub-case of the broader procedure detailed in Section 4.2, adapted to a single Broadcast Domain environment. The absence of an SBD simplifies the configuration, as all signaling remains within the context of BD1.
この例は、単一のブロードキャストドメイン環境に適合したセクション4.2で詳述されているより広範な手順の特定のサブケースを表しています。すべてのシグナル伝達がBD1のコンテキスト内に残っているため、SBDが存在しないと構成が簡素化されます。
This section specifies the Hot Standby solution for handling redundant multicast sources (G-sources). The solution supports both IPv4 and IPv6 sources.
このセクションでは、冗長なマルチキャストソース（G-Sources）を処理するためのホットスタンバイソリューションを指定します。このソリューションは、IPv4ソースとIPv6ソースの両方をサポートします。
The Hot Standby solution is designed for scenarios requiring fast failover in the event of a G-source or upstream PE failure. It assumes that additional bandwidth consumption in the tenant network is acceptable. The procedure is as follows:
ホットスタンバイソリューションは、Gソースまたは上流のPE障害が発生した場合に高速フェールオーバーを必要とするシナリオ向けに設計されています。テナントネットワークでの追加の帯域幅消費が許容できると想定しています。手順は次のとおりです。
1. Configuration of PEs
1. PESの構成
* Upstream PEs are configured to identify Single Flow Groups in the tenant domain. This includes groups for any source or a source prefix containing redundant G-sources.
* 上流のPEは、テナントドメイン内の単一のフローグループを識別するように構成されています。これには、冗長なG-ソースを含むソースまたはソースプレフィックスのグループが含まれます。
* Each redundant G-source MUST be associated with an ES on the upstream PEs. This applies to both single-homed and multi-homed G-sources. For both, single-homed and multi-homed G-sources, ESI labels are essential for Reverse Path Forwarding checks on downstream PEs. The term S-ESI is used to denote the ESI associated with a redundant G-source.
* 各冗長なGソースは、上流のPESのESに関連付けられている必要があります。これは、シングルホームとマルチホームの両方のGソースに適用されます。シングルホームとマルチホームのG-ソースの両方について、ESIラベルは、下流のPESの逆パス転送チェックに不可欠です。S-ESIという用語は、冗長なGソースに関連するESIを示すために使用されます。
* Unlike the Warm Standby solution, the Hot Standby solution requires downstream PEs to support the procedure.
* 温かいスタンバイソリューションとは異なり、ホットスタンバイソリューションでは、手順をサポートするために下流のPESが必要です。
* Downstream PEs:
* 下流のPES：
- Do not need explicit configuration for Single Flow Groups or their ESIs (since they get that information from the upstream PEs).
- 単一のフローグループまたはそのESIの明示的な構成は必要ありません（上流のPESからその情報を取得するため）。
- Dynamically select an ESI for each Single Flow Group based on local policy (hence different downstream PEs may select different ESIs) and program a Reverse Path Forwarding check to discard (*,G) or (S,G) packets from other ESIs.
- ローカルポリシー（したがって、異なる下流のPESが異なるESIを選択する場合があります）に基づいて、各フローグループのESIを動的に選択し、他のESIから廃棄する（*、g）または（s、g）パケットを逆パス転送チェックをプログラムします。
2. Signaling the location of a G-source for a given SFG and its association to the local ESes
2. 特定のSFGのGソースの位置とその関連性の地元のESEへのシグナル
An upstream PE configured for Hot Standby procedures:
ホットスタンバイ手順用に構成された上流のPE：
* MUST advertise an S-PMSI A-D route for each Single Flow Group. These routes:
* 単一のフローグループごとにS-PMSI A-Dルートを宣伝する必要があります。これらのルート：
- Use the Broadcast Domain Route Target (BD-RT) and, if applicable, the SBD-RT so that the routes are imported in all the PEs of the tenant domain.
- ブロードキャストドメインルートターゲット（BD-RT）を使用し、該当する場合はSBD-RTを使用して、ルートがテナントドメインのすべてのPESにインポートされるようにします。
- MUST include ESI Label Extended Communities to convey the S-ESI labels associated with the Single Flow Group. These ESI labels match the labels advertised by the EVPN A-D per ES routes for each S-ES.
- ESIラベル拡張コミュニティを含めて、単一のフローグループに関連するS-ESIラベルを伝える必要があります。これらのESIラベルは、各S-EのESルートごとにeVPN A-Dによって宣伝されているラベルと一致します。
* MAY include a PMSI Tunnel Attribute, depending on the tunnel type, as specified in the Warm Standby procedure.
* 温かいスタンバイ手順で指定されているように、トンネルの種類に応じて、PMSIトンネル属性を含めることができます。
* MUST trigger the S-PMSI A-D route advertisement based on the SFG configuration (and not based on the reception of traffic).
* SFG構成に基づいてS-PMSI A-Dルート広告をトリガーする必要があります（トラフィックの受信に基づいていません）。
3. Distribution of DCB ESI labels and G-source ES routes
3. DCB ESIラベルとGソースESルートの分布
* Upstream PEs advertise corresponding EVPN routes:
* 上流のPESは、対応するEVPNルートを宣伝します。
- EVPN ES routes for the local S-ESIs. ES routes are used for regular DF Election for the S-ES. This document does not introduce any change in the procedures related to the EVPN ES routes.
- EVPNは、ローカルS-ESTのルートです。ESルートは、S-ESの定期的なDF選挙に使用されます。このドキュメントでは、EVPN ESルートに関連する手順に変更が導入されません。
- 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 per ES routes MUST include the route target SBD-RT, since they have to be imported by all the PEs in the tenant domain.
- テナント固有のトラフィックの場合、EVIあたりのA-DおよびESあたりのA-D。SBDが存在する場合、EVIあたりのEVPN A-DおよびESルートごとのA-Dには、テナントドメインのすべてのPESによってインポートする必要があるため、ルートターゲットSBD-RTを含める必要があります。
* ESI label procedures:
* ESIラベル手順：
- The EVPN A-D per ES routes convey the S-ESI labels that the downstream PEs use to implement Reverse Path Forwarding checks for SFGs.
- ES RURTESごとのEVPN A-Dは、下流のPESがSFGの逆パス転送チェックを実装するために使用する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-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 "Ly" for S-ES-2. In addition, Lx and Ly MUST be different.
- 特定のGソースのすべてのパケットは、同じS-ESIラベルを搭載する必要があります。たとえば、2つの冗長なg-sourceがS-ES-1およびS-ES-2を介してPE1とPE2にマルチホームされている場合、PE1とPE2はS-ES-1に同じESIラベル「LX」を割り当てる必要があり、S-ES-2に同じESIラベル「LY」を割り当てる必要があります。さらに、LXとLyは異なる必要があります。
- S-ESI labels are allocated as Domain-wide Common Block (DCB) labels and follow the procedures in [RFC9573]. In addition, the PE indicates that these ESI labels are DCB labels by using the extensions described in Section 5.2.
- S-ESIラベルは、ドメイン全体の共通ブロック（DCB）ラベルとして割り当てられ、[RFC9573]の手順に従います。さらに、PEは、これらのESIラベルがセクション5.2で説明されている拡張機能を使用してDCBラベルであることを示しています。
4. Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on the downstream PEs
4. ES/EVIルートごとのEVPN A-Dの処理および下流のPESでのパス転送チェック
The EVPN A-D per ES/EVI routes are received and imported in all the PEs in the tenant domain. Downstream PEs process received EVPN A-D per ES/EVI routes based on their configuration:
ES/EVIルートごとのEVPN A-Dが受信され、テナントドメインのすべてのPESでインポートされます。下流のPESプロセスは、その構成に基づいてES/EVIルートごとにEVPN A-Dを受信しました。
* 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 routes process the routes as in [RFC7432] and [RFC8584]. If the receiving PE is attached to the same ES as indicated in the route, split-horizon procedures [RFC7432] are followed and the DF Election candidate list is modified as in [RFC8584] if the ES supports the AC-DF (AC influenced DF) capability.
* EVPN A-D/EVIルートに含まれるルートターゲットBD-RTの同じブロードキャストドメインに接続されたPESは、[RFC7432]および[RFC8584]のようにルートを処理します。受信PEがルートに示されているのと同じESに接続されている場合、Split-Horizon手順[RFC7432]が遵守され、DF選挙候補リストが[RFC8584]のように修正され、ESがAC-DF（ACに影響を受けたDF）機能をサポートします。
* The PEs that are not attached to the Broadcast Domain identified by the BD-RT but are attached to the SBD of the received SBD-RT MUST import the EVPN A-D per ES/EVI routes and use them for redundant G-source mass withdrawal, as explained later.
* BD-RTによって識別されたブロードキャストドメインに接続されていないが、受信したSBD-RTのSBDに接続されているPESは、ES/EVIルートごとにEVPN A-Dをインポートし、後で説明するように冗長なG-Source Mass Abtempalに使用する必要があります。
* Upon importing EVPN A-D per ES routes corresponding to different S-ESes, a PE MUST select a primary S-ES based on local policy, and add a Reverse Path Forwarding check to the (*,G) or (S,G) state in the Broadcast Domain or SBD. This Reverse Path Forwarding check discards all ingress packets to (*,G)/(S,G) that are not received with the ESI label of the primary S-ES.
* 異なるS-ESEに対応するES-D-eSルートごとにEVPN A-Dをインポートすると、PEはローカルポリシーに基づいてプライマリS-Eを選択し、放送ドメインまたはSBDの（*、g）または（s、g）状態に逆パス転送チェックを追加する必要があります。この逆パス転送チェックすべての侵入パケットは、プライマリS-ESのESIラベルで受信されない（*、g）/（s、g）に廃棄します。
5. G-traffic forwarding for redundant G-sources and fault detection
5. 冗長なG-ソースと障害検出のためのGトラフィック転送
* Traffic forwarding with S-ESI labels:
* S-ESIラベルを使用したトラフィック転送：
- When there is an existing (*,G) or (S,G) state for the SFG with output interface list entries associated with remote EVPN PEs, the upstream PE will add an S-ESI label to the bottom of the stack when forwarding G-traffic received on an S-ES. This label is allocated from a DCB as described in Step 3.
- リモートEVPN PESに関連付けられた出力インターフェイスリストエントリを備えたSFGに既存（*、g）または（s、g）状態がある場合、上流のPEは、S-ESで受信したGトラフィックを転送するときにS-ESIラベルをスタックの下部に追加します。このラベルは、ステップ3で説明されているようにDCBから割り当てられます。
- If point-to-multipoint or BIER PMSIs are used, this procedure does not introduce new data path requirements on the upstream PEs, apart from allocating the S-ESI label from the DCB as per [RFC9573]). However, when IR or AR are employed, this document extends the procedures defined in [RFC7432]. In these scenarios, the upstream PE pushes the S-ESI labels on packets not only destined for PEs sharing the ES but also for all PEs within the tenant domain. This ensures that downstream PEs receive all the multicast packets from the redundant G-sources with an S-ESI label, regardless of the PMSI type or local ESes. Downstream PEs will discard any packet carrying an S-ESI label different from the primary S-ESI label (associated with the selected primary S-ES), as outlined in Step 4.
- Point-to-MultipointまたはBier PMSIを使用している場合、この手順では、[RFC9573]に従ってDCBからS-ESIラベルを割り当てる以外に、上流のPESに新しいデータパス要件を導入しません。ただし、IRまたはARを使用すると、このドキュメントは[RFC7432]で定義されている手順を拡張します。これらのシナリオでは、上流のPEは、ESを共有するPESだけでなく、テナントドメイン内のすべてのPEに対してもPESに向けられたパケット上のS-ESIラベルを押します。これにより、PMSIタイプやローカルESEに関係なく、下流のPEが冗長なGソースからすべてのマルチキャストパケットを受信することが保証されます。下流のPESは、ステップ4で概説されているように、プライマリS-ESIラベル（選択したプライマリS-ESに関連付けられている）とは異なるS-ESIラベルを運ぶパケットを破棄します。
* Handling route withdrawals and fault detection
* 取り扱いルートの引き出しと障害検出
- 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 update the Reverse Path Forwarding check accordingly.
- プライマリS-ESのEVIあたりの最後のEVPN A-DまたはプライマリS-ESのES-D-eSルートごとの最後のEVPN A-Dが撤回される場合、下流のPEはすぐに新しいプライマリS-ESを選択し、それに応じてリバースパス転送チェックを更新します。
- For scenarios where the same S-ES is used across multiple tenant domains by the upstream PEs, the withdrawal of all the EVPN A-D per-ES routes associated with an S-ES enables a mass withdrawal mechanism. This allows the downstream PE to simultaneously update the Reverse Path Forwarding check for all tenant domains that rely on the same S-ES.
- 上流のPESによって複数のテナントドメインで同じS-ESが使用されるシナリオの場合、S-ESに関連付けられたすべてのEVPN A-D PER-ESルートの撤退により、大量離脱メカニズムが可能になります。これにより、下流のPEは、同じS-Eに依存するすべてのテナントドメインの逆パス転送チェックを同時に更新できます。
* Removal of Reverse Path Forwarding checks on S-PMSI withdrawal
* S-PMSI撤回の逆パス転送チェックの削除
- The withdrawal of the last EVPN S-PMSI A-D route for a given (*,G) or (S,G) that represents an SFG SHOULD result in the downstream PE removing the S-ESI label-based Reverse Path Forwarding check for that (*,G) or (S,G).
- SFGを表す特定の（*、g）または（s、g）の最後のEVPN S-PMSI A-Dルートの撤回は、S-ESIラベルベースの逆パス転送チェックを（*、g）または（s、g）の下流のPEが除去することになります。
This document supports the use of Context-Specific Label Space ID Extended Communities, as described in [RFC9573], for scenarios where S-ESI labels are allocated within context-specific label spaces. When the context-specific 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-specific label space identified by the DCB label in the Extended Community.
このドキュメントは、[RFC9573]で説明されているように、コンテキスト固有のラベルスペース内でS-ESIラベルが割り当てられているシナリオについて、コンテキスト固有のラベルスペースID拡張コミュニティの使用をサポートしています。コンテキスト固有のラベルスペースID拡張コミュニティがEVPN A-DあたりルートのESIラベルとともに宣伝される場合、ESIラベルは、拡張コミュニティのDCBラベルによって識別されるコンテキスト固有のラベル空間からのものです。
DCB labels are specified in [RFC9573], and this document makes use of them as outlined in Section 5.1. [RFC9573] assumes that DCB labels are applicable only to Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels. Additionally, it specifies that when a PMSI label is a DCB label, the ESI label used for multi-homing is also a DCB label.
DCBラベルは[RFC9573]で指定されており、このドキュメントはセクション5.1で概説されているようにそれらを利用しています。[RFC9573]は、DCBラベルがマルチポイントツーマルチポイント、ポイントツーマルチポイント、またはビアトンネルにのみ適用可能であると仮定しています。さらに、PMSIラベルがDCBラベルである場合、マルチホミングに使用されるESIラベルもDCBラベルであることを指定しています。
This document extends the use of DCB-allocated ESI labels with the following provisions:
このドキュメントは、次の規定でDCBに割り当てられたESIラベルの使用を拡張します。
a. DCB-allocated ESI labels MAY be used with IR tunnels and
a. DCBに割り当てられたESIラベルは、IRトンネルで使用できます。
b. DCB-allocated ESI labels MAY be used by PEs that do not use DCB-allocated PMSI labels.
b. DCBに割り当てられたESIラベルは、DCBに割り当てられたPMSIラベルを使用していないPESによって使用できます。
These control plane extensions are indicated in the EVPN A-D per ES routes for the relevant S-ESes by:
これらの制御プレーン拡張は、関連するS-ESEのEVPN A-Dごとに示されています。
1. Adding the ESI-DCB-flag (DCB flag) to the ESI label Extended Community, or
1. ESI-DCB-FLAG（DCBフラグ）をESIラベル拡張コミュニティに追加する、または
2. Adding the Context-Specific Label Space ID extended community
2. コンテキスト固有のラベルスペースID拡張コミュニティを追加します
The encoding of the DCB-flag within the ESI Label Extended Community is shown below:
ESIラベル拡張コミュニティ内のDCB-FLAGのエンコードを以下に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ESI Label Extended Community
図6：ESIラベル拡張コミュニティ
This document defines the DCB-flag as follows:
このドキュメントでは、DCB-FLAGを次のように定義しています。
* Bit 5 of the Flags octet in the ESI Label Extended Community is defined as the ESI-DCB-flag by this document.
* ESIラベル拡張コミュニティのフラグオクテットのビット5は、このドキュメントによってESI-DCB-Flagとして定義されています。
* When the ESI-DCB-flag is set, it indicates that the ESI label is a DCB label.
* ESI-DCB-FLAGが設定されている場合、ESIラベルがDCBラベルであることを示します。
Criteria for identifying a DCB label:
DCBラベルを識別するための基準：
An ESI label is considered a DCB label if either of the following conditions is met:
ESIラベルは、次の条件のいずれかが満たされている場合、DCBラベルと見なされます。
a. The ESI label is encoded in an ESI Label Extended Community with the ESI-DCB-flag set.
a. ESIラベルは、ESI-DCB-FLAGセットを備えたESIラベル拡張コミュニティにエンコードされています。
b. The ESI label is signaled by a PE that has advertised a PMSI label that is a DCB label.
b. ESIラベルは、DCBラベルであるPMSIラベルを宣伝したPEによって信号を送ります。
As in [RFC9573], this document also permits the use of context-specific label space ID extended community. When this extended community is advertised along with the ESI label in an EVPN A-D per ES route, it indicates that the ESI label is from a context-specific label space identified by the DCB label in the Extended Community.
[RFC9573]のように、このドキュメントでは、コンテキスト固有のラベルスペースID拡張コミュニティの使用も許可しています。この拡張コミュニティがESIルートごとのEVPN A-DのESIラベルとともに宣伝されると、ESIラベルは、拡張コミュニティのDCBラベルによって識別されたコンテキスト固有のラベル空間からのものであることを示します。
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 checks for (*,G) or (S,G) as discussed in Section 5.1, the Bidirectional Forwarding Detection (BFD) protocol MAY be employed to monitor the status of the multipoint tunnels used to forward the SFG packets from redundant G-sources.
EVIあたりのEVPN A-D、EVPN A-DあたりのEVPN A-D、またはS-PMSI A-Dルートの状態を利用して、セクション5.1で説明したように（*、g）または（s、g）逆パス転送チェックを調整することに加えて、双方向転送検出（BFD）プロトコルを使用して、Gsurscesを介して採用するために採用される場合があります。
BFD integration:
BFD統合：
* The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or IMET routes, depending on whether Inclusive PMSI or Selective PMSI trees are being utilized.
* BGP-BFD属性は、包括的PMSIまたは選択的PMSIツリーが利用されているかどうかに応じて、S-PMSI A-DまたはIMETルートとともに宣伝されます。
* The procedures outlined in [RFC9780] are followed to bootstrap multipoint BFD sessions on the downstream PEs.
* [RFC9780]で概説されている手順は、下流のPESでのブートストラップマルチポイントBFDセッションに続きます。
This section describes the Hot Standby model applied in an Optimized Inter-Subnet Multicast (OISM) network. Figures 7 and 8 illustrate scenarios with multi-homed and single-homed redundant G-sources, respectively.
このセクションでは、最適化されたサブネット間マルチキャスト（OISM）ネットワークに適用されるホットスタンバイモデルについて説明します。図7と8は、それぞれマルチホームとシングルホームの冗長なGソースを使用したシナリオを示しています。
Scenario (Figure 7):
シナリオ（図7）：
* S1 and S2 are redundant G-sources for the Single Flow Group (*,G1), connected to BD1.
* S1とS2は、BD1に接続された、単一のフローグループ（*、G1）の冗長なGソースです。
* S1 and S2 are all-active multi-homed to upstream PEs (PE1 and PE2).
* S1とS2は、上流のPES（PE1およびPE2）に対してすべてのマルチホームです。
* Receivers are connected to downstream PEs (PE3 and PE5) in BD3 and BD1, respectively.
* 受信機は、それぞれBD3およびBD1の下流PES（PE3およびPE5）に接続されています。
* S1 and S2 are connected to the multi-homing PEs using a LAG. Multicast traffic can traverse either link.
* S1とS2は、遅れを使用してマルチホミングPEに接続されています。マルチキャストトラフィックは、いずれかのリンクを通過できます。
* In this model, downstream PEs receive duplicate G-traffic for (*,G1) and must use Reverse Path Forwarding checks to avoid delivering duplicate packets to receivers.
* このモデルでは、ダウンストリームPEは重複したGトラフィック（*、G1）を受け取り、レシーバーに重複パケットを配信しないように逆パス転送チェックを使用する必要があります。
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/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1)
Figure 7: Hot Standby Solution for Multi-Homed Redundant G-Sources in OISM
図7：OISMにおけるマルチホームの冗長なGソースのためのホットスタンバイソリューション
The procedure is as follows:
手順は次のとおりです。
1. Configuration of the PEs:
1. PESの構成：
* PE1 and PE2 are configured to recognize (*,G1) as a Single Flow Group.
* PE1とPE2は、単一のフローグループとして（*、G1）を認識するように構成されています。
* Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 for S2.
* 冗長なG-ソースは、S-S1のESI-1を使用し、S2にESI-2を使用します。
* The ESes (ES-1 and ES-2) are configured on both PEs. ESI labels are allocated from a DCB [RFC9573] - ESI-label-1 for ESI-1 and ESI-label-2 for ESI-2.
* ESE（ES-1およびES-2）は両方のPESで構成されています。ESIラベルは、DCB [RFC9573] -ESI-1のESI-Label-1、ESI-2に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.
* ダウンストリームPES（PE3、PE4、およびPE5）は、ホットスタンバイモードをサポートし、最低のESI値でGソースを選択するように構成されています。
2. Advertisement of the EVPN routes:
2. EVPNルートの広告：
* PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), including:
* PE1およびPE2は、以下を含む（*、G1）のS-PMSI A-Dルートを宣伝します。
- Route Targets: BD1-RT and SBD-RT.
- ルートターゲット：BD1-RTおよびSBD-RT。
- ESI Label Extended Communities for ESI-label-1 and ESI-label-2.
- ESIラベルESI-Label-1およびESI-Label-2の拡張コミュニティ。
- The SFG flag indicating that (*,G1) represents a Single Flow Group.
- （*、G1）が単一のフローグループを表すことを示すSFGフラグ。
* 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 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 PEs).
* ESI-1およびESI-2については、EVPN ESおよびA-DがESI-1およびESI-2についても宣伝されています。これらには、下流のPEインポート用のSBD-RTが含まれます。ESI-1（PESの両方で）のESI-Label-1およびESI-2のESI-Label-2（両方のPES）のESI-Label-1が含まれています。
3. Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on downstream PEs:
3. ES/EVIルートごとのEVPN A-Dの処理および下流のPESでのパス転送チェックを逆にする：
* PE1 and PE2 receive each other's ES and A-D per ES/EVI routes. DF Election and programming of the ESI labels for egress split-horizon filtering follow, as specified in [RFC7432] and [RFC8584].
* PE1とPE2は、互いのESとA-DをES/EVIルートごとに受け取ります。[RFC7432]および[RFC8584]で指定されているように、出力分裂硬化フィルタリングのESIラベルのDF選挙とプログラミング。
* PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD; PE5 imports them in BD1.
* PE3/PE4は、SBDのES/EVIルートごとにEVPN A-Dをインポートします。PE5はそれらをBD1にインポートします。
* As downstream PEs, PE3 and PE5 use the EVPN A-D per ES/EVI routes to program Reverse Path Forwarding checks.
* 下流のPESとして、PE3とPE5はEVPN A-D 1 ES/EVIルートを使用して、パス転送チェックを逆にプログラムします。
* The primary S-ESI for (*,G1) is selected based on local policy (e.g., lowest ESI value), and therefore packets with ESI-label-2 are discarded if ESI-label-1 is selected as the primary label.
* （*、G1）の主要なS-ESIは、ローカルポリシー（例えば、ESI値が最も低い）に基づいて選択されるため、ESI-Label-1がプライマリラベルとして選択されている場合、ESI-Label-2のパケットが破棄されます。
4. Traffic forwarding and fault detection:
4. 交通転送と障害検出：
* PE1 receives (S1,G1) traffic and forwards it with ESI-label-1 in the context of BD1. This traffic passes Reverse Path Forwarding checks on downstream PEs (PE3 and PE5, since PE4 has no local interested receivers) and is delivered to receivers.
* PE1は（S1、G1）トラフィックを受け取り、BD1のコンテキストでESI-Label-1で転送します。このトラフィックは、下流のPES（PE3およびPE5の逆パス転送チェック（PE4にはローカルな関心のあるレシーバーがないため）を通過し、受信機に配信されます。
* PE2 receives (S2,G1) traffic and forwards it with ESI-label-2. This traffic fails the Reverse Path Forwarding check on PE3 and PE5 and is discarded.
* PE2は（S2、G1）トラフィックを受け取り、ESI-Label-2で転送します。このトラフィックは、PE3とPE5の逆パス転送チェックに失敗し、破棄されます。
* If the link between S1 and PE1 fails, PE1 withdraws the EVPN ES and A-D routes for ESI-1. S1 forwards the (S1,G1) traffic to PE2 instead. PE2 continues forwarding (S2,G1) traffic using ESI-label-2 and now also forwards (S1,G1) with ESI-label-1. The Reverse Path Forwarding checks do not change in PE3/PE5.
* S1とPE1の間のリンクが失敗した場合、PE1はESI-1のEVPN ESとA-Dルートを引き出します。S1は（S1、G1）トラフィックを代わりにPE2に転送します。PE2は、ESI-Label-2を使用して転送（S2、G1）トラフィックを継続し、現在はESI-Label-1を転送（S1、G1）も進めています。逆パス転送チェックは、PE3/PE5で変化しません。
* If all links to S1 fail, PE2 also withdraws the EVPN ES and A-D routes for ESI-1 and downstream PEs update the Reverse Path Forwarding checks to accept ESI-label-2 traffic.
* S1へのすべてのリンクが失敗した場合、PE2はESI-1のEVPN ESおよびA-Dルートも引き出し、下流のPESはESI-Label-2トラフィックを受け入れるために逆パス転送チェックを更新します。
Scenario (Figure 8):
シナリオ（図8）：
* S1 is single-homed to PE1 using ESI-1, and S2 is single-homed to PE2 using ESI-2.
* S1はESI-1を使用してPE1にシングルホームされており、S2はESI-2を使用してPE2に単一ホームされています。
* The scenario is a subset of the multi-homed case. Only one PE advertises EVPN A-D per ES/EVI routes for each S-ESI.
* シナリオは、マルチホームケースのサブセットです。S-ESIごとにES/EVIルートごとにEVPN A-Dを宣伝するのは1つだけです。
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/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1)
Figure 8: HS Solution for Single-Homed Redundant G-Sources in OISM
図8：OISMにおける単一給の冗長なG-ソースのためのHSソリューション
The procedures follow the same logic as described in the multi-homed scenario, with the distinction that each ESI is specific to a single PE.
手順は、各ESIが単一のPEに固有であるという区別を伴う、マルチホームのシナリオで説明されているのと同じロジックに従います。
Figures 7 and 8 demonstrate the application of the Hot Standby solution, ensuring seamless traffic forwarding while avoiding duplication in the presence of redundant G-sources.
図7と8は、ホットスタンバイソリューションの適用を示しており、シームレスなトラフィックの転送を保証しながら、冗長なG-ソースの存在下での重複を避けています。
The Hot Standby procedures described in Section 5.4 apply equally to scenarios where the tenant network comprises a single Broadcast Domain (e.g., BD1), irrespective of whether the redundant G-sources are multi-homed or single-homed. In such cases:
セクション5.4で説明されているホットスタンバイ手順は、冗長なG-ソースがマルチホームまたはシングルホームであるかどうかに関係なく、テナントネットワークが単一のブロードキャストドメイン（BD1など）を含むシナリオに等しく適用されます。そのような場合：
* The advertised routes do not include the SBD-RT.
* 宣伝されているルートには、SBD-RTが含まれていません。
* All procedures are confined to the single BD1.
* すべての手順は、単一のBD1に限定されます。
The absence of the SBD simplifies the configuration and limits the scope of the Hot Standby solution to BD1, while maintaining the integrity of the procedures for managing redundant G-sources.
SBDが存在しないと、構成が簡素化され、Hot Standbyソリューションの範囲がBD1に制限され、冗長なGソースを管理する手順の整合性を維持します。
The same Security Considerations described in [RFC9625] are valid for this document.
[RFC9625]で説明されているのと同じセキュリティ上の考慮事項は、このドキュメントに有効です。
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.
セキュリティの観点からは、このドキュメントで説明されている2つの方法のうち、暖かいスタンバイ方法はコントロールプレーンの点で軽量と見なされるため、PESの処理機能に影響が低くなります。ホットスタンバイ方法は、ソースとレシーバーを備えたテナントのすべてのPEのコントロールプレーンにより多くの負担を追加します。
IANA has allocated bit 4 in the "Multicast Flags Extended Community" registry that was introduced by [RFC9251]. This bit indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is associated with an SFG. This bit is called "Single Flow Group" bit, and it is defined as follows:
IANAは、[RFC9251]によって導入された「マルチキャストフラグ拡張コミュニティ」レジストリにビット4を割り当てました。このビットは、S-PMSI A-Dルートの特定の（*、g）または（s、g）がSFGに関連付けられていることを示しています。このビットは「シングルフローグループ」ビットと呼ばれ、次のように定義されています。
+=====+===================+===============+
| Bit | Name | Reference |
+=====+===================+===============+
| 4 | Single Flow Group | This Document |
+-----+-------------------+---------------+
Table 1
IANA has allocated bit 5 in the "EVPN ESI Label Extended Community Flags" registry that was introduced by [RFC9746]. This bit is the ESI-DCB flag and indicates that the ESI label contained in the ESI Label Extended Community is a DCB label. This bit is defined as follows:
IANAは、[RFC9746]によって導入された「EVPN ESIラベル拡張コミュニティフラグ」レジストリにビット5を割り当てました。このビットはESI-DCBフラグであり、ESIラベル拡張コミュニティに含まれるESIラベルがDCBラベルであることを示しています。このビットは次のように定義されています。
+=====+=========+===============+
| Bit | Name | Reference |
+=====+=========+===============+
| 5 | ESI-DCB | This Document |
+-----+---------+---------------+
Table 2
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[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>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>.
[RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan,
J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast
(OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August
2024, <https://www.rfc-editor.org/info/rfc9625>.
[RFC9746] Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "BGP
EVPN Multihoming Extensions for Split-Horizon Filtering",
RFC 9746, DOI 10.17487/RFC9746, March 2025,
<https://www.rfc-editor.org/info/rfc9746>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
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.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[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.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, May 2024,
<https://www.rfc-editor.org/info/rfc9572>.
[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
A. Sajassi, "Optimized Ingress Replication Solution for
Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/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>.
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.
著者は、マンカマナ・ミシュラ、アリ・サジャシ、グレッグ・ミルスキー、サーシャ・ヴァインシュテインのレビューと貴重なコメントに感謝したいと思います。Gunter Van De Veldeが優れたレビューをしてくれたことに感謝します。これにより、ドキュメントの読みやすさが大幅に向上しました。
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
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Jayant Kotalwar
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jayant.kotalwar@nokia.com
Senthil Sathappan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: senthil.sathappan@nokia.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Wen Lin
Juniper Networks
Email: wlin@juniper.net