Internet Engineering Task Force (IETF) W. Lin
Request for Comments: 9625 Z. Zhang
Category: Standards Track J. Drake
ISSN: 2070-1721 E. Rosen, Ed.
Juniper Networks, Inc.
J. Rabadan
Nokia
A. Sajassi
Cisco Systems
August 2024
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple segments. Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single tenant owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter-subnet multicast traffic and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined to be external to the EVPN domain.
Ethernet VPN（EVPN）は、単一のIPサブネットを含む単一のローカルエリアネットワーク（LAN）を複数のセグメントに分割できるようにするサービスを提供します。各セグメントは別のサイトに配置される場合があり、セグメントはIPまたはMPLSバックボーンによって相互接続されています。サブネット内トラフィック（ユニキャストまたはマルチキャストのいずれか）は、実際にIPまたはMPLSバックボーンを介して運ばれている場合でも、常にエンドユーザーにブリッジされるように見えます。単一のテナントがこのようなLANを複数所有している場合、EVPNはIPユニキャストトラフィックをそれらのLAN間でルーティングすることもできます。このドキュメントは、サブネット内のIPマルチキャストトラフィックを特定のテナントのLAN間でルーティングできるようにする新しい手順を指定し、サブネット内のIPマルチキャストトラフィックを橋渡ししているように見えるようにしています。これらの手順は、Subnet Inter-Subnetマルチキャストトラフィックの最適なルーティングを提供することができ、特定のルーターを脱出してから同じルーターを侵入するためにそのようなトラフィックを必要としません。これらの手順は、EVPNドメインの外部に発生するか、運命づけられるIPマルチキャストトラフィックにも対応します。
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/rfc9625.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9625で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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.1.1. Requirements Language
1.2. Background
1.2.1. Segments, Broadcast Domains, and Tenants
1.2.2. Inter-BD (Inter-Subnet) IP Traffic
1.2.3. EVPN and IP Multicast
1.2.4. BDs, MAC-VRFs, and EVPN Service Models
1.3. Need for EVPN-Aware Multicast Procedures
1.4. Additional Requirements That Must Be Met by the Solution
1.5. Model of Operation: Overview
1.5.1. Control Plane
1.5.2. Data Plane
2. Detailed Model of Operation
2.1. Supplementary Broadcast Domain
2.2. Detecting When a Route is for/from a Particular BD
2.3. Use of IRB Interfaces at Ingress PE
2.4. Use of IRB Interfaces at an Egress PE
2.5. Announcing Interest in (S,G)
2.6. Tunneling Frames from Ingress PEs to Egress PEs
2.7. Advanced Scenarios
3. EVPN-Aware Multicast Solution Control Plane
3.1. Supplementary Broadcast Domain (SBD) and Route Targets
3.2. Advertising the Tunnels Used for IP Multicast
3.2.1. Constructing Routes for the SBD
3.2.2. Ingress Replication
3.2.3. Assisted Replication
3.2.3.1. Automatic SBD Matching
3.2.4. BIER
3.2.5. Inclusive P2MP Tunnels
3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive
Tunnels
3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise
Inclusive Tunnels Specific to IP Multicast
3.2.6. Selective Tunnels
3.3. Advertising SMET Routes
4. Constructing Multicast Forwarding State
4.1. Layer 2 Multicast State
4.1.1. Constructing the OIF List
4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame
4.1.2.1. Eligibility of an AC to Receive a Frame
4.1.2.2. Applying the OIF List
4.2. Layer 3 Forwarding State
5. Interworking with Non-OISM EVPN PEs
5.1. IPMG Designated Forwarder
5.2. Ingress Replication
5.2.1. Ingress PE is Non-OISM
5.2.2. Ingress PE is OISM
5.3. P2MP Tunnels
6. Traffic to/from Outside the EVPN Tenant Domain
6.1. Layer 3 Interworking via EVPN OISM PEs
6.1.1. General Principles
6.1.2. Interworking with MVPN
6.1.2.1. MVPN Sources with EVPN Receivers
6.1.2.1.1. Identifying MVPN Sources
6.1.2.1.2. Joining a Flow from an MVPN Source
6.1.2.2. EVPN Sources with MVPN Receivers
6.1.2.2.1. General Procedures
6.1.2.2.2. Any-Source Multicast (ASM) Groups
6.1.2.2.3. Source on Multihomed Segment
6.1.2.3. Obtaining Optimal Routing of Traffic between MVPN
and EVPN
6.1.2.4. Selecting the MEG SBD-DR
6.1.3. Interworking with Global Table Multicast
6.1.4. Interworking with PIM
6.1.4.1. Source Inside EVPN Domain
6.1.4.2. Source Outside EVPN Domain
6.2. Interworking with PIM via an External PIM Router
7. Using an EVPN Tenant Domain as an Intermediate (Transit)
Network for Multicast Traffic
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Integrated Routing and Bridging
Acknowledgements
Authors' Addresses
In this document, we make frequent use of the following terminology:
このドキュメントでは、次の用語を頻繁に使用します。
OISM:
oism：
Optimized Inter-Subnet Multicast. EVPN PEs that follow the procedures of this document will be known as "OISM" Provider Edges (PEs). EVPN PEs that do not follow the procedures of this document will be known as "non-OISM" PEs.
最適化されたサブネット間マルチキャスト。このドキュメントの手順に従うEVPN PEは、「OISM」プロバイダーエッジ（PES）として知られています。このドキュメントの手順に従わないEVPN PEは、「非オイズム」PESとして知られています。
IP Multicast Packet:
IPマルチキャストパケット：
An IP packet whose IP Destination Address field is a multicast address that is not a link-local address. (Link-local addresses are IPv4 addresses in the 224/24 range and IPv6 addresses in the FF02/16 range.)
IP宛先アドレスフィールドがリンクローカルアドレスではないマルチキャストアドレスであるIPパケット。（Link-Localアドレスは、224/24範囲のIPv4アドレスとFF02/16範囲のIPv6アドレスです。）
IP Multicast Frame:
IPマルチキャストフレーム：
An Ethernet frame whose payload is an IP multicast packet (as defined above).
ペイロードがIPマルチキャストパケットであるイーサネットフレーム（上記で定義）。
(S,G) Multicast Packet:
（S、G）マルチキャストパケット：
An IP multicast packet whose Source IP Address field contains S and whose IP Destination Address field contains G.
ソースIPアドレスフィールドにSが含まれ、IP宛先アドレスフィールドにGが含まれているIPマルチキャストパケット。
(S,G) Multicast Frame:
（S、G）マルチキャストフレーム：
An IP multicast frame whose payload contains S in its Source IP Address field and G in its IP Destination Address field.
ペイロードがソースIPアドレスフィールドにSを含むIPマルチキャストフレームと、IP宛先アドレスフィールドにGが含まれています。
EVI:
EVI:
EVPN Instance. An EVPN instance spanning the PE devices participating in that EVPN.
EVPNインスタンス。そのEVPNに参加するPEデバイスにまたがるEVPNインスタンス。
BD:
BD:
Broadcast Domain. An emulated Ethernet, such that two systems on the same BD will receive each other's link-local broadcasts.
ブロードキャストドメイン。同じBD上の2つのシステムが互いのLink-Localブロードキャストを受信するように、エミュレートされたイーサネット。
Note that EVPN supports service models in which a single EVI contains only one BD and service models in which a single EVI contains multiple BDs. Both types of service models are supported by this document. In all models, a given BD belongs to only one EVI.
EVPNは、単一のEVIに1つのBDと1つのサービスモデルのみが含まれるサービスモデルをサポートしていることに注意してください。単一のEVIには複数のBDが含まれています。両方のタイプのサービスモデルは、このドキュメントでサポートされています。すべてのモデルで、特定のBDは1つのEVIのみに属します。
DF:
DF:
Designated Forwarder. As defined in [RFC7432], an Ethernet segment may be multihomed (attached to more than one PE). An Ethernet segment 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]で定義されているように、イーサネットセグメントはマルチホームになっている可能性があります（複数のPEに取り付けられています）。イーサネットセグメントには、1つ以上のEVIの複数のBDが含まれる場合があります。そのようなEVIそれぞれについて、セグメントに接続されたPEの1つは、そのセグメントのEVIのDFになります。BDは1つのEVIのみに属する可能性があるため、特定のセグメントについてBDのDFを明確に話すことができます。
AC:
AC:
Attachment Circuit. An AC connects the bridging function of an EVPN PE to an Ethernet segment of a particular BD. ACs are not visible at the Layer 3.
アタッチメント回路。ACは、EVPN PEのブリッジング関数を特定のBDのイーサネットセグメントに接続します。ACSはレイヤー3では見えません。
If a given Ethernet segment, attached to a given PE, contains n BDs, we say that the PE has n ACs to that segment.
特定のPEに接続された特定のイーサネットセグメントにN BDSが含まれている場合、PEにはそのセグメントにN ACSがあると言います。
L3 Gateway:
L3ゲートウェイ：
An L3 Gateway is a PE that connects an EVPN Tenant Domain to an external multicast domain by performing both the OISM procedures and the Layer 3 multicast procedures of the external domain.
L3ゲートウェイは、EVPNテナントドメインを外部マルチキャストドメインに接続するPEで、OISMプロシージャとレイヤー3外部ドメインのマルチキャスト手順の両方を実行します。
PEG:
PEG:
PIM/EVPN Gateway. An L3 Gateway that connects an EVPN Tenant Domain to an external multicast domain whose Layer 3 multicast procedures are those of PIM [RFC7761].
PIM/EVPNゲートウェイ。EVPNテナントドメインを、レイヤー3マルチキャスト手順がPIM [RFC7761]の外部マルチキャストドメインに接続するL3ゲートウェイ。
MEG:
MEG:
MVPN/EVPN Gateway. An L3 Gateway that connects an EVPN Tenant Domain to an external multicast domain whose Layer 3 multicast procedures are those of Multicast VPN (MVPN) [RFC6513] [RFC6514].
MVPN/EVPNゲートウェイ。EVPNテナントドメインを外部マルチキャストドメインに接続するL3ゲートウェイは、レイヤー3マルチキャスト手順であるマルチキャストVPN（MVPN）[RFC6513] [RFC6514]の外部マルチキャストドメインです。
IPMG:
IPMG：
IP Multicast Gateway. A PE that is used for interworking OISM EVPN PEs with non-OISM EVPN PEs.
IPマルチキャストゲートウェイ。非OISM EVPN PESを使用したOISM EVPN PESを介入するために使用されるPE。
DR:
DR:
Designated Router. A PE that has special responsibilities for handling multicast on a given BD.
指定ルーター。特定のBDでマルチキャストを処理するための特別な責任を持つPE。
FHR:
FHR:
First Hop Router. The FHR is a PIM router [RFC7761] with special responsibilities. It is the first multicast router to see (S,G) packets from source S, and if G is an Any-Source Multicast (ASM) group, the FHR is responsible for sending PIM Register messages to the PIM Rendezvous Point (RP) for group G.
最初のホップルーター。FHRは、特別な責任を伴うPIMルーター[RFC7761]です。これは、ソースSから（S、G）パケットを見る最初のマルチキャストルーターであり、Gが任意のソースマルチキャスト（ASM）グループの場合、FHRはPIMレジスタメッセージをPIM Rendezvous Point（RP）に送信する責任があります。グループG.
LHR:
LHR:
Last Hop Router. The LHR is a PIM router [RFC7761] with special responsibilities. Generally, it is attached to a LAN, and it determines whether there are any hosts on the LAN that need to receive a given multicast flow. If so, it creates and sends the PIM Join messages that are necessary to receive the flow.
最後のホップルーター。LHRは、特別な責任を伴うPIMルーター[RFC7761]です。一般に、それはLANに取り付けられており、LANに特定のマルチキャストフローを受信する必要があるホストがあるかどうかを決定します。その場合、フローを受信するために必要なPIM結合メッセージを作成および送信します。
EC:
EC:
Extended Community. A BGP Extended Communities attribute [RFC4360] [RFC7153] is a BGP path attribute that consists of one or more Extended Communities.
拡張コミュニティ。BGP拡張コミュニティ属性[RFC4360] [RFC7153]は、1つ以上の拡張コミュニティで構成されるBGPパス属性です。
RT:
RT:
Route Target. A Route Target is a particular kind of BGP Extended Community. A BGP Extended Community consists of a type field, a sub-type field, and a value field. Certain type/sub-type combinations indicate that a particular Extended Community is an RT. RT1 and RT2 are considered to be the same RT if and only if they have the same type, sub-type, and value fields.
ルートターゲット。ルートターゲットは、特定の種類のBGP拡張コミュニティです。BGP拡張コミュニティは、タイプフィールド、サブタイプフィールド、および値フィールドで構成されています。特定のタイプ/サブタイプの組み合わせは、特定の拡張コミュニティがRTであることを示しています。RT1とRT2は、同じタイプ、サブタイプ、および値フィールドを持っている場合にのみ、同じRTであると見なされます。
C- prefix:
c-プレフィックス：
In many documents on VPN multicast, the prefix C- appears before any address or wildcard that refers to an address or addresses in a tenant's address space rather than to an address of addresses in the address space of the backbone network. This document omits the C- prefix in many cases where it is clear from the context that the reference is to the tenant's address space.
VPNマルチキャストに関する多くのドキュメントでは、接頭辞Cは、バックボーンネットワークのアドレス空間内のアドレスのアドレスではなく、テナントのアドレススペースのアドレスまたはアドレスを指すアドレスまたはワイルドカードの前に表示されます。このドキュメントは、参照がテナントのアドレス空間への参照であることが文脈から明らかである多くの場合にC-プレフィックスを省略します。
This document also assumes familiarity with the terminology of [RFC4364], [RFC6514], [RFC7432], [RFC7761], [RFC9136], [RFC9251], and [RFC9572].
このドキュメントは、[RFC4364]、[RFC6514]、[RFC7432]、[RFC7761]、[RFC9136]、[RFC9251]、[RFC9572]の用語にも精通しています。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer Ethernet service to a set of customers, known as "tenants".
イーサネットVPN（EVPN）[RFC7432]は、「テナント」として知られる一連の顧客にIPまたはMPLSバックボーンプロバイダーがイーサネットサービスを提供できるようにするレイヤー2 VPN（L2VPN）ソリューションを提供します。
In this section (as well as in [RFC9135]), we provide some essential background information on EVPN.
このセクション（および[RFC9135]と同様に）では、EVPNに関するいくつかの重要な背景情報を提供します。
One of the key concepts of EVPN is the Broadcast Domain (BD). A BD is essentially an emulated Ethernet. Each BD belongs to a single tenant. A BD typically consists of multiple Ethernet segments, and each segment may be attached to a different EVPN Provider Edge (EVPN PE) router. EVPN PE routers are often referred to as "Network Virtualization Endpoints (NVEs)". However, this document will use the term "EVPN PE" or, when the context is clear, just "PE".
EVPNの重要な概念の1つは、ブロードキャストドメイン（BD）です。BDは本質的にエミュレートされたイーサネットです。各BDは単一のテナントに属します。BDは通常、複数のイーサネットセグメントで構成され、各セグメントは異なるEVPNプロバイダーエッジ（EVPN PE）ルーターに接続できます。EVPN PEルーターは、多くの場合、「ネットワーク仮想化エンドポイント（NVE）」と呼ばれます。ただし、このドキュメントでは、「EVPN PE」という用語を使用するか、コンテキストが明確な場合は「PE」だけを使用します。
In this document, the term "segment" is used interchangeably with "Ethernet Segment" or "ES", as defined in [RFC7432].
このドキュメントでは、[RFC7432]で定義されているように、「セグメント」という用語は「イーサネットセグメント」または「ES」と交換可能に使用されます。
Attached to each segment are Tenant Systems (TSs). A TS may be any type of system, physical or virtual, host or router, etc., that can attach to an Ethernet.
各セグメントに添付されているのは、テナントシステム（TSS）です。TSは、イーサネットに取り付けることができる、物理的または仮想、または仮想、ホストまたはルーターなど、あらゆるタイプのシステムです。
When two TSs are on the same segment, traffic between them does not pass through an EVPN PE. When two TSs are on different segments of the same BD, traffic between them does pass through an EVPN PE.
2つのTSSが同じセグメントにある場合、それらの間のトラフィックはEVPN PEを通過しません。2つのTSSが同じBDの異なるセグメントにある場合、それらの間のトラフィックはEVPN PEを通過します。
When two TSs, say TS1 and TS2, are on the same BD, then the following occurs:
たとえばTS1とTS2などの2つのTSSが同じBDにいる場合、次のことが発生します。
* If TS1 knows the Media Access Control (MAC) address of TS2, TS1 can send unicast Ethernet frames to TS2. TS2 will receive the frames unaltered.
* TS1がTS2のメディアアクセスコントロール（MAC）アドレスを知っている場合、TS1はユニキャストイーサネットフレームをTS2に送信できます。TS2は、変更されていないフレームを受け取ります。
* If TS1 broadcasts an Ethernet frame, TS2 will receive the unaltered frame.
* TS1がイーサネットフレームをブロードキャストする場合、TS2は変更されていないフレームを受け取ります。
* If TS1 multicasts an Ethernet frame, TS2 will receive the unaltered frame as long as TS2 has been provisioned to receive the Ethernet multicast destination MAC address.
* TS1がイーサネットフレームをマルチキャストする場合、TS2がイーサネットマルチキャスト宛先MACアドレスを受信するようにプロビジョニングされている限り、TS2は変更されていないフレームを受け取ります。
When we say that TS2 receives an unaltered frame from TS1, we mean that the frame still contains TS1's MAC address and that no alteration of the frame's payload (and consequently, no alteration of the payload's IP header) has been made.
TS2がTS1から変更されていないフレームを受け取ると言うと、フレームにはまだTS1のMACアドレスが含まれており、フレームのペイロードの変更がないことを意味します（その結果、ペイロードのIPヘッダーの変更はありません）。
EVPN allows a single segment to be attached to multiple PE routers. This is known as "EVPN multihoming". Suppose a given segment is attached to both PE1 and PE2, and suppose PE1 receives a frame from that segment. It may be necessary for PE1 to send the frame over the backbone to PE2. EVPN has procedures to ensure that such a frame cannot be sent back to its originating segment by PE2. This is particularly important for multicast, because a frame arriving at PE1 from a given segment will already have been seen by all the systems on that segment that need to see it. If the frame was sent back to the originating segment by PE2, receivers on that segment would receive the packet twice. Even worse, the frame might be sent back to PE1, which could cause an infinite loop.
EVPNを使用すると、単一のセグメントを複数のPEルーターに接続できます。これは「EVPN Multihoming」として知られています。特定のセグメントがPE1とPE2の両方に接続されていると仮定し、PE1がそのセグメントからフレームを受信すると仮定します。PE1がバックボーンを介してフレームをPE2に送信する必要がある場合があります。EVPNには、そのようなフレームをPE2によってその発生セグメントに送り返すことができないことを確認する手順があります。これはマルチキャストにとって特に重要です。これは、特定のセグメントからPE1に到着するフレームが、それを見る必要があるセグメントのすべてのシステムですでに見られているためです。フレームがPE2によって発信セグメントに送られた場合、そのセグメントの受信機は2回パケットを受け取ります。さらに悪いことに、フレームはPE1に送り返される可能性があり、これにより無限のループが発生する可能性があります。
If a given tenant has multiple BDs, the tenant may wish to allow IP communication among these BDs. Such a set of BDs is known as an "EVPN Tenant Domain" or just a "Tenant Domain".
特定のテナントに複数のBDSがある場合、テナントはこれらのBDS間のIP通信を許可したい場合があります。このような一連のBDSは、「EVPNテナントドメイン」または単なる「テナントドメイン」として知られています。
If tenant systems TS1 and TS2 are not in the same BD, then they do not receive unaltered Ethernet frames from each other. In order for TS1 to send traffic to TS2, TS1 encapsulates an IP datagram inside an Ethernet frame and uses Ethernet to send these frames to an IP router. The router decapsulates the IP datagram, does the IP processing, and re-encapsulates the datagram for Ethernet. The MAC Source Address field now has the MAC address of the router, not of TS1. The TTL field of the IP datagram should be decremented by exactly 1, even if the frame needs to be sent from one PE to another. The structure of the provider's backbone is thus hidden from the tenants.
テナントシステムTS1とTS2が同じBDにない場合、変更されていないイーサネットフレームを互いに受け取りません。TS1がTS2にトラフィックを送信するために、TS1はイーサネットフレーム内のIPデータグラムをカプセル化し、イーサネットを使用してこれらのフレームをIPルーターに送信します。ルーターはIPデータグラムをデカプセルし、IP処理を行い、イーサネットのデータグラムを再カプセル化します。MACソースアドレスフィールドには、TS1ではなく、ルーターのMACアドレスが搭載されています。IPデータグラムのTTLフィールドは、フレームをあるPEから別のPEに送信する必要がある場合でも、正確に1だけ減少する必要があります。したがって、プロバイダーのバックボーンの構造は、テナントから隠されています。
EVPN accommodates the need for inter-BD communication within a Tenant Domain by providing an integrated L2/L3 service for unicast IP traffic. EVPN's Integrated Routing and Bridging (IRB) functionality is specified in [RFC9135]. Each BD in a Tenant Domain is assumed to be a single IP subnet, and each IP subnet within a given Tenant Domain is assumed to be a single BD. EVPN's IRB functionality allows IP traffic to travel from one BD to another and ensures that proper IP processing (e.g., TTL decrement) is done.
EVPNは、ユニキャストIPトラフィックに統合されたL2/L3サービスを提供することにより、テナントドメイン内のBD間通信の必要性に対応します。EVPNの統合ルーティングとブリッジング（IRB）機能は、[RFC9135]で指定されています。テナントドメイン内の各BDは単一のIPサブネットであると想定されており、特定のテナントドメイン内の各IPサブネットは単一のBDであると想定されています。EVPNのIRB機能により、IPトラフィックはあるBDから別のBDへの移動を可能にし、適切なIP処理（TTLの減少など）が完了することを保証します。
A brief overview of IRB, including the notion of an IRB interface, can be found in Appendix A. As explained there, an IRB interface is a sort of virtual interface connecting an L3 routing instance to a BD. A BD may have multiple Attachment Circuits (ACs) to a given PE, where each AC connects to a different Ethernet segment of the BD. However, these ACs are not visible to the L3 routing function; from the perspective of an L3 routing instance, a PE has just one interface to each BD, viz., the IRB interface for that BD.
IRBインターフェイスの概念を含むIRBの簡単な概要は、付録Aにあります。そこで説明したように、IRBインターフェイスはL3ルーティングインスタンスをBDに接続する一種の仮想インターフェイスです。BDには、特定のPEへの複数のアタッチメントサーキット（ACS）があり、各ACがBDの異なるイーサネットセグメントに接続します。ただし、これらのACはL3ルーティング機能には見えません。L3ルーティングインスタンスの観点から見ると、PEには各BDに1つのインターフェイスしかありません。つまり、そのBDのIRBインターフェイスです。
In this document, when traffic is routed out of an IRB interface, we say it is sent down the IRB interface to the BD that the IRB is for. In the other direction, traffic is sent up the IRB interface from the BD to the L3 routing instance.
このドキュメントでは、トラフィックがIRBインターフェイスからルーティングされている場合、IRBのインターフェイスをBDに送信していると言います。他の方向では、トラフィックはBDからL3ルーティングインスタンスにIRBインターフェイスを送信します。
The L3 routing instance depicted in Appendix A is associated with a single Tenant Domain and may be thought of as IP Virtual Routing and Forwarding (IP-VRF) for that Tenant Domain.
付録Aに描かれているL3ルーティングインスタンスは、単一のテナントドメインに関連付けられており、そのテナントドメインのIP仮想ルーティングおよび転送（IP-VRF）と考えられる場合があります。
[RFC9135] and [RFC9136] cover inter-subnet (inter-BD) IP unicast forwarding, but they do not cover inter-subnet IP multicast forwarding.
[RFC9135]および[RFC9136]は、インターサブネット（INTER-BD）IPユニキャスト転送をカバーしていますが、インターサブネットIPマルチキャスト転送をカバーしていません。
[RFC7432] covers intra-subnet (intra-BD) Ethernet multicast. The intra-subnet Ethernet multicast procedures of [RFC7432] are used for Ethernet broadcast traffic, Ethernet unicast traffic whose Destination MAC Address field contains an unknown address, and Ethernet traffic whose Destination MAC Address field contains an Ethernet multicast MAC address. These three classes of traffic are known collectively as "BUM traffic" (Broadcast, Unknown Unicast, or Multicast traffic), and the procedures for handling BUM traffic are known as "BUM procedures".
[RFC7432]は、サブネット内（BD内）イーサネットマルチキャストをカバーしています。[RFC7432]のサブネット内イーサネットマルチキャスト手順は、イーサネットブロードキャストトラフィック、宛先MACアドレスフィールドに未知のアドレスが含まれているイーサネットユニキャストトラフィック、および宛先MACアドレスフィールドにイーサネットマルチキャストMACアドレスが含まれているイーサネットトラフィックに使用されます。これらの3つのクラスのトラフィックは、集合的に「バムトラフィック」（放送、不明なユニキャスト、またはマルチキャストトラフィック）として知られており、バムトラフィックを処理する手順は「バム手順」として知られています。
[RFC9251] extends the intra-subnet Ethernet multicast procedures by adding procedures that are specific to, and optimized for, the use of IP multicast within a subnet. However, that document does not cover inter-subnet IP multicast.
[RFC9251]サブネット内でIPマルチキャストの使用に固有の手順を追加し、最適化された手順を追加することにより、サブネット内イーサネットマルチキャスト手順を拡張します。ただし、そのドキュメントでは、サブネット間IPマルチキャストをカバーしていません。
The purpose of this document is to specify procedures for EVPN that provide optimized IP multicast functionality within an EVPN Tenant Domain. This document also specifies procedures that allow IP multicast packets to be sourced from or destined to systems outside the Tenant Domain. The entire set of procedures are referred to as "Optimized Inter-Subnet Multicast (OISM)" procedures.
このドキュメントの目的は、EVPNテナントドメイン内で最適化されたIPマルチキャスト機能を提供するEVPNの手順を指定することです。このドキュメントは、IPマルチキャストパケットをテナントドメイン以外のシステムから調達または運命づける手順も指定しています。手順のセット全体は、「最適化されたサブネット間マルチキャスト（OISM）」手順と呼ばれます。
In order to support the OISM procedures specified in this document, an EVPN PE MUST also support [RFC9135] and [RFC9251]. (However, certain procedures in [RFC9251] are modified when OISM is supported.)
このドキュメントで指定されたOISM手順をサポートするために、EVPN PEは[RFC9135]および[RFC9251]もサポートする必要があります。（ただし、[RFC9251]の特定の手順は、OISMがサポートされているときに変更されます。）
[RFC7432] defines the notion of MAC-VRF (MAC Virtual Routing and Forwarding). A MAC-VRF contains one or more bridge tables (see Section 3 of [RFC7432]), each of which represents a single Broadcast Domain.
[RFC7432]は、MAC-VRF（MAC仮想ルーティングと転送）の概念を定義します。MAC-VRFには、1つ以上のブリッジテーブル（[RFC7432]のセクション3を参照）が含まれており、それぞれが単一のブロードキャストドメインを表しています。
In the IRB model (outlined in Appendix A), an L3 routing instance has one IRB interface per BD, NOT one per MAC-VRF. This document does not distinguish between a Broadcast Domain and a bridge table; instead, it uses the terms interchangeably (or will use the acronym "BD" to refer to either). The way the BDs are grouped into MAC-VRFs is not relevant to the procedures specified in this document.
IRBモデル（付録Aに概説）では、L3ルーティングインスタンスには、MAC-VRFごとではなく、BDごとに1つのIRBインターフェイスがあります。このドキュメントでは、ブロードキャストドメインとブリッジテーブルを区別しません。代わりに、用語を交換可能に使用します（または、「BD」という頭字語を使用してどちらを参照します）。BDSをMAC-VRFにグループ化する方法は、このドキュメントで指定された手順には関係ありません。
Section 6 of [RFC7432] also defines several different EVPN service models:
[RFC7432]のセクション6では、いくつかの異なるEVPNサービスモデルも定義しています。
* In the vlan-based service, each MAC-VRF contains one bridge table, where the bridge table corresponds to a particular Virtual LAN (VLAN) (see Section 3 of [RFC7432]). Thus, each VLAN is treated as a BD.
* VLANベースのサービスでは、各MAC-VRFには1つのブリッジテーブルが含まれており、ブリッジテーブルは特定の仮想LAN（VLAN）に対応しています（[RFC7432]のセクション3を参照）。したがって、各VLANはBDとして扱われます。
* In the vlan bundle service, each MAC-VRF contains one bridge table, where the bridge table corresponds to a set of VLANs. Thus, a set of VLANs are treated as constituting a single BD.
* VLANバンドルサービスでは、各Mac-VRFには1つのブリッジテーブルがあり、ブリッジテーブルはVLANのセットに対応しています。したがって、VLANのセットは、単一のBDを構成するものとして扱われます。
* In the vlan-aware bundle service, each MAC-VRF may contain multiple bridge tables, where each bridge table corresponds to one BD. If a MAC-VRF contains several bridge tables, then it corresponds to several BDs.
* VLAN-Awareバンドルサービスでは、各Mac-VRFには複数のブリッジテーブルが含まれている場合があり、各ブリッジテーブルは1つのBDに対応しています。MAC-VRFにいくつかのブリッジテーブルが含まれている場合、いくつかのBDに対応します。
The procedures in this document are intended to work for all these service models.
このドキュメントの手順は、これらすべてのサービスモデルで機能することを目的としています。
Inter-subnet IP multicast among a set of BDs can be achieved, in a non-optimal manner, without any specific EVPN procedures. For instance, if a particular tenant has n BDs among which it wants to send IP multicast traffic, it can simply attach a conventional multicast router to all n BDs. Or more generally, as long as each BD has at least one IP multicast router, and the IP multicast routers communicate multicast control information with each other, conventional IP multicast procedures will work normally, and no special EVPN functionality is needed.
一連のBDS間のサブネット間IPマルチキャストは、特定のEVPN手順なしで、最適ではない方法で達成できます。たとえば、特定のテナントがIPマルチキャストトラフィックを送信したいN BDSを持っている場合、従来のマルチキャストルーターをすべてのN BDに添付するだけです。またはより一般的には、各BDに少なくとも1つのIPマルチキャストルーターがあり、IPマルチキャストルーターがマルチキャスト制御情報を互いに通信している限り、従来のIPマルチキャスト手順は正常に機能し、特別なEVPN機能は必要ありません。
However, that technique does not provide optimal routing for multicast. In conventional multicast routing, for a given multicast flow, there is only one multicast router on each BD that is permitted to send traffic of that flow to the BD. If that BD has receivers for a given flow, but the source of the flow is not on that BD, then the flow must pass through that multicast router. This leads to the hairpinning problem described (for unicast) in Appendix A.
ただし、その手法では、マルチキャストに最適なルーティングを提供しません。従来のマルチキャストルーティングでは、特定のマルチキャストフローについて、各BDには、そのフローのトラフィックをBDに送信できるマルチキャストルーターは1つだけです。そのBDには特定のフローの受信機があるが、フローのソースがそのBD上にない場合、フローはそのマルチキャストルーターを通過する必要があります。これは、付録Aで（ユニキャストの場合）説明されているヘアピニングの問題につながります。
For example, consider an (S,G) flow that is sourced by a TS S and needs to be received by TSs R1 and R2. Suppose S is on a segment of BD1, R1 is on a segment of BD2, but both are attached to PE1. Also suppose that the tenant has a multicast router attached to a segment of BD1 and to a segment of BD2. However, the segments to which that router is attached are both attached to PE2. Then, the flow from S to R would have to follow the path: S-->PE1-->PE2-->tenant multicast router-->PE2-->PE1-->R1. Obviously, the path S-->PE1-->R would be preferred.
たとえば、TS sによって供給され、TSS R1およびR2が受信する必要がある（s、g）フローを考慮してください。SがBD1のセグメントにあると仮定します。R1はBD2のセグメントにありますが、両方がPE1に接続されています。また、テナントには、BD1のセグメントとBD2のセグメントに取り付けられたマルチキャストルーターがあると仮定します。ただし、そのルーターが取り付けられているセグメントは両方ともPE2に取り付けられています。次に、sからrへの流れは、パスに従う必要があります：s-> pe1-> pe2->テナントマルチキャストルーター - > pe2-> pe1-> r1。明らかに、パスs-> pe1-> rが推奨されます。
+---+ +---+
|PE1+----------------------+PE2|
+---+-+ +-+---+
| \ \ / / |
BD1 BD2 BD3 BD3 BD2 BD1
| | | \ | |
S R1 R2 router
Now suppose that there is a second receiver, R2. R2 is attached to a third BD, BD3. However, it is attached to a segment of BD3 that is attached to PE1. And suppose that the tenant multicast router is attached to a segment of BD3 that attaches to PE2. In this case, the tenant multicast router will make two copies of the packet, one for BD2 and one for BD3. PE2 will send both copies back to PE1. Not only is the routing sub-optimal, but PE2 also sends multiple copies of the same packet to PE1, which is a further sub-optimality.
次に、2番目のレシーバーR2があると仮定します。R2は、3番目のBD、BD3に取り付けられています。ただし、PE1に取り付けられているBD3のセグメントに取り付けられています。また、テナントマルチキャストルーターがPE2に付着するBD3のセグメントに取り付けられていると仮定します。この場合、テナントマルチキャストルーターは、BD2用、もう1つはBD3用に2つのパケットのコピーを作成します。PE2は両方のコピーをPE1に送り返します。ルーティングは次の最適であるだけでなく、PE2も同じパケットの複数のコピーをPE1に送信します。これはさらにサブオプティマリティです。
This is only an example; many more examples of sub-optimal multicast routing can easily be given. To eliminate sub-optimal routing and extra copies, it is necessary to have a multicast solution that is EVPN-aware and that can use its knowledge of the internal structure of a Tenant Domain to ensure that multicast traffic gets routed optimally. The procedures in this document allow us to avoid all such sub-optimalities when routing inter-subnet multicast traffic within a Tenant Domain.
これは単なる例です。最適なマルチキャストルーティングのより多くの例を簡単に提供できます。準最適ルーティングと追加のコピーを排除するには、EVPNが認識し、テナントドメインの内部構造に関する知識を使用して、マルチキャストトラフィックが最適にルーティングされるようにするために、マルチキャストソリューションを使用する必要があります。このドキュメントの手順により、テナントドメイン内のサブネット間マルチキャストトラフィックをルーティングする際に、そのようなすべての最適性を回避できます。
In addition to providing optimal routing of multicast flows within a Tenant Domain, the EVPN-aware multicast solution is intended to satisfy the following requirements:
テナントドメイン内のマルチキャストフローの最適なルーティングを提供することに加えて、EVPNに対応するマルチキャストソリューションは、次の要件を満たすことを目的としています。
* The solution must integrate well with the procedures specified in [RFC9251]. That is, an integrated set of procedures must handle both intra-subnet multicast and inter-subnet multicast.
* ソリューションは、[RFC9251]で指定された手順と十分に統合する必要があります。つまり、統合された一連の手順は、サブネット内マルチキャストとサブネット間マルチキャストの両方を処理する必要があります。
* With regard to intra-subnet multicast, the solution MUST maintain the integrity of the multicast Ethernet service. This means:
* サブネット内マルチキャストに関しては、ソリューションはマルチキャストイーサネットサービスの完全性を維持する必要があります。これはつまり：
- If a source and a receiver are on the same subnet, the MAC Source Address (SA) of the multicast frame sent by the source will not get rewritten.
- ソースとレシーバーが同じサブネット上にある場合、ソースが送信したマルチキャストフレームのMACソースアドレス（SA）は書き直されません。
- If a source and a receiver are on the same subnet, no IP processing of the Ethernet payload is done. The IP TTL is not decremented, the IPv4 header checksum is not changed, no fragmentation is done, etc.
- ソースとレシーバーが同じサブネット上にある場合、イーサネットペイロードのIP処理は行われません。IP TTLは減少せず、IPv4ヘッダーチェックサムは変更されず、断片化も行われません。
* On the other hand, if a source and a receiver are on different subnets, the frame received by the receiver will not have the MAC Source Address of the source, as the frame will appear to have come from a multicast router. Also, proper processing of the IP header is done, e.g., TTL decrements by 1, header checksum modification, possible fragmentation, etc.
* 一方、ソースとレシーバーが異なるサブネットにある場合、フレームはマルチキャストルーターから来たように見えるため、レシーバーが受信したフレームにソースのMACソースアドレスがありません。また、IPヘッダーの適切な処理が行われます。たとえば、TTLの減少、ヘッダーチェックサムの変更、可能な断片化など。
* If a Tenant Domain contains several BDs, it MUST be possible for a multicast flow (even when the multicast group address is an ASM address) to have sources in one of those BDs and receivers in one or more of the other BDs without requiring the presence of any system performing PIM RP functions [RFC7761].
* テナントドメインに複数のBDSが含まれている場合、マルチキャストフロー（マルチキャストグループアドレスがASMアドレスである場合でも）が可能である必要があります。PIM RP機能を実行するシステム[RFC7761]。
* Sometimes a MAC address used by one TS on a particular BD is also used by another TS on a different BD. Inter-subnet routing of multicast traffic MUST NOT make any assumptions about the uniqueness of a MAC address across several BDs.
* 特定のBDで1つのTSが使用するMACアドレスが別のBDで別のTSによって使用される場合もあります。マルチキャストトラフィックのサブネット間ルーティングは、いくつかのBDSにわたるMACアドレスの一意性について仮定してはなりません。
* If two EVPN PEs attached to the same Tenant Domain both support the OISM procedures, each may receive inter-subnet multicasts from the other, even if the egress PE is not attached to any segment of the BD from which the multicast packets are being sourced. It MUST NOT be necessary to provision the egress PE with knowledge of the ingress BD.
* 同じテナントドメインに接続された2つのEVPN PEが両方ともOISM手順をサポートする場合、出口PEがマルチキャストパケットが調達されているBDのどのセグメントにも接続されていない場合でも、それぞれが他の手順からインターサブネットマルチキャストを受け取ることがあります。侵入BDの知識を持って出口PEをプロビジョニングする必要はありません。
* There must be a procedure that allows EVPN PE routers supporting OISM procedures to send/receive multicast traffic to/from EVPN PE routers that support only [RFC7432] but that does not support the OISM procedures or even the procedures of [RFC9135]. However, when interworking with such routers (which we call "non-OISM PE routers"), optimal routing may not be achievable.
* OISM手順をサポートするEVPN PEルーターが、[RFC7432]のみをサポートするEVPN PEルーターにマルチキャストトラフィックを送信/受信することを可能にする手順が必要ですが、それはOISM手順や[RFC9135]の手順さえサポートしていません。ただし、そのようなルーター（「非オイズムPEルーター」と呼ばれる）と相互作用する場合、最適なルーティングは達成できない場合があります。
* It MUST be possible to support scenarios in which multicast flows with sources inside a Tenant Domain have external receivers, i.e., receivers that are outside the domain. It must also be possible to support scenarios where multicast flows with external sources (sources outside the Tenant Domain) have receivers inside the domain.
* テナントドメイン内にソースを使用してマルチキャストが流れるシナリオをサポートすることは、外部レシーバー、つまりドメインの外側にあるレシーバーを備えている必要があります。また、マルチキャストが外部ソース（テナントドメインの外側のソース）がドメイン内にレシーバーを備えているシナリオをサポートすることも可能である必要があります。
This presupposes that unicast routes to multicast sources outside the domain can be distributed to EVPN PEs attached to the domain and that unicast routes to multicast sources within the domain can be distributed outside the domain.
これにより、ドメイン外のマルチキャストソースへのユニキャストルートは、ドメインに接続されたEVPN PESに分布し、ドメイン内のマルチキャストソースへのユニキャストルートをドメイン外に分配できます。
Of particular importance are the scenarios in which the external sources and/or receivers are reachable via L3VPN/MVPN or via IP/ PIM.
特に重要なのは、外部ソースおよび/または受信機がL3VPN/MVPNまたはIP/PIMを介して到達可能なシナリオです。
The solution for external interworking MUST allow for deployment scenarios in which EVPN does not need to export a host route for every multicast source.
外部インターワーキングのソリューションは、EVPNがすべてのマルチキャストソースのホストルートをエクスポートする必要がない展開シナリオを可能にする必要があります。
* The solution for external interworking must not presuppose that the same tunneling technology is used within both the EVPN domain and the external domain. For example, MVPN interworking must be possible when MVPN is using MPLS Point-to-Multipoint (P2MP) tunneling and when EVPN is using Ingress Replication (IR) or Virtual eXtensible Local Area Network (VXLAN) tunneling.
* 外部インターワーキングのソリューションは、EVPNドメインと外部ドメインの両方で同じトンネリング技術が使用されていることを前提としてはなりません。たとえば、MVPNがMPLSポイントツーマルチポイント（P2MP）トンネルを使用している場合、およびEVPNがイングレスレプリケーション（IR）または仮想拡張可能なローカルエリアネットワーク（VXLAN）トンネルを使用している場合、MVPNインターワーキングが可能でなければなりません。
* The solution must not be overly dependent on the details of a small set of use cases but must be adaptable to new use cases as they arise. (That is, the solution must be robust.)
* ソリューションは、ユースケースの小さなセットの詳細に過度に依存してはなりませんが、発生したときに新しいユースケースに適応できる必要があります。（つまり、解決策は堅牢でなければなりません。）
In this section, and in the remainder of this document, we assume the reader is familiar with the procedures of IGMP / Multicast Listener Discovery (MLD) (see [RFC3376] and [RFC3810]), by which hosts announce their interest in receiving particular multicast flows.
このセクションでは、このドキュメントの残りの部分では、読者はIGMP /マルチキャストリスナーディスカバリー（MLD）の手順に精通していると仮定します（[RFC3376]および[RFC3810]を参照）。マルチキャストフロー。
Consider a Tenant Domain consisting of a set of k BDs: BD1, ..., BDk. To support the OISM procedures, each Tenant Domain must also be associated with a Supplementary Broadcast Domain (SBD). An SBD is treated in the control plane as a real BD, but it does not have any ACs. The SBD has several uses; these will be described later in this document (see Sections 2.1 and 3).
K BDS：BD1、...、BDKのセットで構成されるテナントドメインを検討してください。OISM手順をサポートするには、各テナントドメインも補足放送ドメイン（SBD）に関連付ける必要があります。SBDはコントロールプレーンで実際のBDとして扱われますが、ACSはありません。SBDにはいくつかの用途があります。これらについては、このドキュメントの後半で説明します（セクション2.1および3を参照）。
Each PE that attaches to one or more of the BDs in a given Tenant Domain will be provisioned to recognize that those BDs are part of the same Tenant Domain. Note that a given PE does not need to be configured with all the BDs of a given Tenant Domain. In general, a PE will only be attached to a subset of the BDs in a given Tenant Domain and will be configured only with that subset of BDs. However, each PE attached to a given Tenant Domain must be configured with the SBD for that Tenant Domain.
特定のテナントドメイン内の1つ以上のBDSに付着する各PEは、これらのBDが同じテナントドメインの一部であることを認識するためにプロビジョニングされます。特定のPEは、特定のテナントドメインのすべてのBDSで構成する必要はないことに注意してください。一般に、PEは特定のテナントドメインのBDSのサブセットにのみ接続され、BDSのサブセットでのみ構成されます。ただし、特定のテナントドメインに接続された各PEは、そのテナントドメインのSBDで構成する必要があります。
Suppose a particular segment of a particular BD is attached to PE1. [RFC7432] specifies that PE1 must originate an Inclusive Multicast Ethernet Tag (IMET) route for that BD and that the IMET route must be propagated to all other PEs attached to the same BD. If the given segment contains a host that has interest in receiving a particular multicast flow, either an (S,G) flow or a (*,G) flow, PE1 will learn of that interest by participating in the IGMP/MLD snooping procedures, as specified in [RFC4541]. In this case:
特定のBDの特定のセグメントがPE1に接続されているとします。[RFC7432]は、PE1がそのBDの包括的なマルチキャストイーサネットタグ（IMET）ルートを発信する必要があり、IMETルートを同じBDに接続した他のすべてのPEに伝播する必要があることを指定します。特定のセグメントに、特定のマルチキャストフローの受信に関心のあるホストが含まれている場合、（s、g）フローまたは（*、g）フローのいずれかで、PE1はIGMP/MLDスヌーピング手順に参加することでその関心を学びます。[RFC4541]で指定されているとおり。この場合：
* PE1 is interested in receiving the flow;
* PE1はフローの受信に関心があります。
* the AC attaching the interested host to PE1 is also said to be interested in the flow; and
* 関心のあるホストをPE1に取り付けるACは、フローに興味があるとも言われています。そして
* the BD containing an AC that is interested in a particular flow is also said to be interested in that flow.
* 特定のフローに関心のあるACを含むBDも、その流れに関心があると言われています。
Once PE1 determines that it has an AC that is interested in receiving a particular flow or set of flows, it originates one or more Selective Multicast Ethernet Tag (SMET) routes [RFC9251] to advertise that interest.
PE1が特定のフローまたは一連のフローを受信することに関心のあるACを持っていると判断すると、その関心を宣伝するために1つまたは複数の選択的マルチキャストイーサネットタグ（SMET）ルート[RFC9251]が発生します。
Note that each IMET or SMET route is for a particular BD. The notion of a route being for a particular BD is explained in Section 2.2.
各IMETまたはSMETルートは特定のBD用であることに注意してください。特定のBDのルートであるという概念は、セクション2.2で説明されています。
When OISM is being supported, the procedures of [RFC9251] are modified as follows:
OISMがサポートされている場合、[RFC9251]の手順は次のように変更されます。
* The IMET route originated by a particular PE for a particular BD is distributed to all other PEs attached to the Tenant Domain containing that BD, even to those PEs that are not attached to that particular BD.
* 特定のBDの特定のPEから発生するIMETルートは、そのBDを含むテナントドメインに付随する他のすべてのPEに分布しています。
* The SMET routes originated by a particular PE are originated on a per-Tenant-Domain basis rather than a per-BD basis. That is, the SMET routes are considered to be for the Tenant Domain's SBD rather than any of its ordinary BDs. These SMET routes are distributed to all the PEs attached to the Tenant Domain.
* 特定のPEによって発信されるSMETルートは、BDごとのベースではなく、テナントごとのドメインごとに発信されます。つまり、SMETルートは、通常のBDのいずれではなく、テナントドメインのSBD用であると考えられています。これらのSMETルートは、テナントドメインに接続されたすべてのPEに分散されています。
In this way, each PE attached to a given Tenant Domain learns, from the other PEs attached to the same Tenant Domain, the set of flows that are of interest to each of those other PEs.
このようにして、特定のテナントドメインに接続された各PEは、同じテナントドメインに取り付けられた他のPESから、他のPEのそれぞれにとって興味深いフローのセットから学習します。
An OISM PE that is provisioned with several BDs in the same Tenant Domain MUST originate an IMET route for each such BD. To indicate its support of [RFC9251], it SHOULD attach the EVPN Multicast Flags Extended Community to each such IMET route, but it MUST attach the EC to at least one such IMET route.
同じテナントドメインに複数のBDでプロビジョニングされたOISM PEは、そのようなBDごとにIMETルートを発生する必要があります。[RFC9251]のサポートを示すには、EVPNマルチキャストフラグ拡張コミュニティをそのようなIMETルートごとに接続する必要がありますが、ECを少なくとも1つのIMETルートに接続する必要があります。
Suppose PE1 is provisioned with both BD1 and BD2 and considers them to be part of the same Tenant Domain. It is possible that PE1 will receive both an IMET route for BD1 and an IMET route for BD2 from PE2. If either of these IMET routes has the EVPN Multicast Flags Extended Community, PE1 MUST assume that PE2 is supporting the procedures of [RFC9251] for ALL BDs in the Tenant Domain.
PE1がBD1とBD2の両方でプロビジョニングされ、それらが同じテナントドメインの一部であると見なされるとします。PE1は、BD1のIMETルートとPE2からBD2のIMETルートの両方を受け取る可能性があります。これらのIMETルートのいずれかにEVPNマルチキャストフラグが拡張されたコミュニティがある場合、PE1はPE2がテナントドメイン内のすべてのBDSの[RFC9251]の手順をサポートしていると想定する必要があります。
If a PE supports OISM functionality, it indicates that, by setting the OISM-supported flag in the Multicast Flags Extended Community, it attaches to some or all of its IMET routes. An OISM PE SHOULD attach this EC with the OISM-supported flag set to all the IMET routes it originates. However, if PE1 imports IMET routes from PE2, and at least one of PE2's IMET routes indicates that PE2 is an OISM PE, PE1 MUST assume that PE2 is following OISM procedures.
PEがOISM機能をサポートする場合、MultiCast Flags Extended CommunityにOISMがサポートするフラグを設定することにより、IMETルートの一部またはすべてに付着することを示します。Oism PEは、このECを、由来するすべてのIMETルートに設定されたOISMサポートフラグに添付する必要があります。ただし、PE1がPE2からIMETルートをインポートし、PE2のIMETルートの少なくとも1つがPE2がOISM PEであることを示している場合、PE1はPE2がOISM手順に従っていると仮定する必要があります。
Suppose PE1 has an AC to a segment in BD1 and PE1 receives an (S,G) multicast frame from that AC (as defined in Section 1.1).
PE1がBD1にACからセグメントを持っていると仮定し、PE1がそのACから（s、g）マルチキャストフレームを受け取るとします（セクション1.1で定義されています）。
There may be other ACs of PE1 on which TSs have indicated an interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 is responsible for sending the received multicast packet on those ACs. There are two cases to consider:
TSSが（S、G）マルチキャストパケットに関心を示しているPE1の他のACSがある場合があります。PE1は、これらのACSで受信したマルチキャストパケットを送信する責任があります。考慮すべき2つのケースがあります。
* Intra-Subnet Forwarding: In this case, an AC with interest in (S,G) is connected to a segment that is part of the source BD, BD1. If the segment is not multihomed, or if PE1 is the Designated Forwarder (DF) (see [RFC7432]) for that segment, PE1 sends the multicast frame on that AC without changing the MAC SA. The IP header is not modified at all; in particular, the TTL is not decremented.
* サブネット内転向：この場合、（s、g）に関心のあるACは、ソースBDの一部であるBD1の一部であるセグメントに接続されています。セグメントがマルチホームになっていない場合、またはPE1が指定された転送業者（DF）（[RFC7432]を参照）である場合、PE1はMAC SAを変更せずにそのACのマルチキャストフレームを送信します。IPヘッダーはまったく変更されていません。特に、TTLは減少しません。
* Inter-Subnet Forwarding: An AC with interest in (S,G) is connected to a segment of BD2, where BD2 is different than BD1. If PE1 is the DF for that segment (or if the segment is not multihomed), PE1 decapsulates the IP multicast packet, performs any necessary IP processing (including TTL decrement), and then re-encapsulates the packet appropriately for BD2. PE1 then sends the packet on the AC. Note that after re-encapsulation, the MAC SA will be PE1's MAC address on BD2. The IP TTL will have been decremented by 1.
* サブネット間転送：（s、g）に関心のあるACは、BD2のセグメントに接続されています。BD2はBD1とは異なります。PE1がそのセグメントのDFである場合（またはセグメントがマルチホームになっていない場合）、PE1はIPマルチキャストパケットを脱カプセル化し、必要なIP処理を実行し（TTL Decrementを含む）、BD2のパケットを適切に再カプセル化します。次に、PE1はACにパケットを送信します。再エンコール化後、MAC SAはBD2のPE1のMACアドレスになることに注意してください。IP TTLは1で減少しています。
In addition, there may be other PEs that are interested in (S,G) traffic. Suppose PE2 is such a PE. Then, PE1 tunnels a copy of the IP multicast frame (with its original MAC SA and with no alteration of the payload's IP header) to PE2. The tunnel encapsulation contains information that PE2 can use to associate the frame with an apparent source BD. If the actual source BD of the frame is BD1, then:
さらに、（s、g）トラフィックに関心のある他のPESがある場合があります。PE2がそのようなPEであると仮定します。次に、PE1がPE2にIPマルチキャストフレームのコピー（元のMac SAとペイロードのIPヘッダーの変更なし）のコピーをトンネルします。トンネルのカプセル化には、PE2がフレームを見かけのソースBDに関連付けるために使用できる情報が含まれています。フレームの実際のソースBDがBD1の場合、次のとおりです。
* If PE2 is attached to BD1, the tunnel encapsulation used to send the frame to PE2 will cause PE2 to identify BD1 as the apparent source BD.
* PE2がBD1に接続されている場合、フレームをPE2に送信するために使用されるトンネルカプセル化により、PE2は見かけのソースBDとしてBD1を識別します。
* If PE2 is not attached to BD1, the tunnel encapsulation used to send the frame to PE2 will cause PE2 to identify the SBD as the apparent source BD.
* PE2がBD1に接続されていない場合、フレームをPE2に送信するために使用されるトンネルのカプセル化により、PE2はSBDを見かけのソースBDとして識別します。
Note that the tunnel encapsulation used for a particular BD will have been advertised in an IMET route or a Selective Provider Multicast Service Interface (S-PMSI) route [RFC9572] for that BD. That route carries a PMSI Tunnel Attribute (PTA), which specifies how packets originating from that BD are encapsulated. This information enables the PE receiving a tunneled packet to identify the apparent source BD as stated above. See Section 3.2 for more details.
特定のBDに使用されるトンネルカプセル化は、IMETルートまたはそのBDの選択的プロバイダーマルチキャストサービスインターフェイス（S-PMSI）ルート[RFC9572]で宣伝されていることに注意してください。そのルートには、PMSIトンネル属性（PTA）が搭載されています。これは、そのBDからのパケットがカプセル化される方法を指定します。この情報により、PEがトンネルパケットを受け取って、上記のように見かけのソースBDを識別することができます。詳細については、セクション3.2を参照してください。
When PE2 receives the tunneled frame, it will forward it on any of its ACs that have interest in (S,G).
PE2がトンネルフレームを受信すると、（s、g）に関心のあるACSのいずれかに転送されます。
If PE2 determines from the tunnel encapsulation that the apparent source BD is BD1, then:
PE2がトンネルのカプセル化から、見かけのソースBDがBD1であると判断した場合、次のとおりです。
* For those ACs that connect PE2 to BD1, the intra-subnet forwarding procedure described above is used, except that it is now PE2, not PE1, carrying out that procedure. Unmodified EVPN procedures from [RFC7432] are used to ensure that a packet originating from a multihomed segment is never sent back to that segment.
* PE2をBD1に接続するACSの場合、上記のサブネット内転送手順が使用されますが、その手順を実行するのはPE2ではなくPE2であることを除いて使用されます。[RFC7432]からの未修正のEVPN手順は、マルチホームセグメントから発信されたパケットがそのセグメントに返送されないようにするために使用されます。
* For those ACs that do not connect to BD1, the inter-subnet forwarding procedure described above is used, except that it is now PE2, not PE1, carrying out that procedure.
* BD1に接続しないACSの場合、上記のスブネット間転送手順が使用されますが、その手順を実行するのはPE2ではなくPE2であることを除いて使用されます。
If the tunnel encapsulation identifies the apparent source BD as the SBD, PE2 applies the inter-subnet forwarding procedures described above to all of its ACs that have interest in the flow.
トンネルのカプセル化が見かけのソースBDをSBDとして識別する場合、PE2は上記のサブネット間転送手順を、フローに関心のあるすべてのACSに適用します。
These procedures ensure that an IP multicast frame travels from its ingress PE to all egress PEs that are interested in receiving it. While in transit, the frame retains its original MAC SA, and the payload of the frame retains its original IP header. Note that in all cases, when an IP multicast packet is sent from one BD to another, these procedures cause its TTL to be decremented by 1.
これらの手順により、IPマルチキャストフレームがイングレスPEからそれを受信することに関心のあるすべての出力PEに移動することを保証します。輸送中に、フレームは元のMac SAを保持し、フレームのペイロードは元のIPヘッダーを保持します。すべての場合において、IPマルチキャストパケットがあるBDから別のBDに送信されると、これらの手順によりTTLが1によって減少することに注意してください。
So far, we have assumed that an IP multicast packet arrives at its ingress PE over an AC that belongs to one of the BDs in a given Tenant Domain. However, it is possible for a packet to arrive at its ingress PE in other ways. Since an EVPN PE supporting IRB has an IP-VRF, it is possible that the IP-VRF will have a VRF interface that is not an IRB interface. For example, there might be a VRF interface that is actually a physical link to an external Ethernet switch, a directly attached host, or a router. When an EVPN PE, say PE1, receives a packet through such means, we will say that the packet has an external source (i.e., a source outside the Tenant Domain). There are also other scenarios in which a multicast packet might have an external source, e.g., it might arrive over an MVPN tunnel from an L3VPN PE. In such cases, we will still refer to PE1 as the "ingress EVPN PE".
これまでのところ、IPマルチキャストパケットが、特定のテナントドメインのBDSの1つに属するAC上に、その侵入PEに到着すると想定しています。ただし、パケットが他の方法でその侵入PEに到達する可能性があります。IRBをサポートするEVPN PEにはIP-VRFがあるため、IP-VRFにはIRBインターフェイスではないVRFインターフェイスがある可能性があります。たとえば、実際には外部イーサネットスイッチへの物理的リンク、直接接続されたホスト、またはルーターへのVRFインターフェイスがある場合があります。EVPN PE（たとえばPE1）がそのような手段を通じてパケットを受け取ると、パケットには外部ソース（つまり、テナントドメインの外側のソース）があると言います。また、マルチキャストパケットに外部ソースがある可能性がある他のシナリオもあります。たとえば、L3VPN PEからMVPNトンネル上に到着する可能性があります。そのような場合、PE1を「イングレスEVPN PE」と呼びます。
When an EVPN PE, say PE1, receives an externally sourced multicast packet, and there are receivers for that packet inside the Tenant Domain, it does the following:
EVPN PE（たとえばPE1）が外部からソースのマルチキャストパケットを受け取り、テナントドメイン内にそのパケットの受信機がある場合、次のことを行います。
* Suppose PE1 has an AC in BD1 that has interest in (S,G). Then, PE1 encapsulates the packet for BD1, filling in the MAC SA field with PE1's own MAC address on BD1. It sends the resulting frame on the AC.
* PE1がBD1に（S、G）に興味があるACがあるとします。次に、PE1がBD1のパケットをカプセル化し、BD1のPE1自身のMACアドレスでMAC SAフィールドを埋めます。結果のフレームをACに送信します。
* Suppose some other EVPN PE, say PE2, has interest in (S,G). PE1 encapsulates the packet for Ethernet, filling in the MAC SA field with PE1's own MAC address on the SBD. PE1 then tunnels the packet to PE2. The tunnel encapsulation will identify the apparent source BD as the SBD. Since the apparent source BD is the SBD, PE2 will know to treat the frame as an inter-subnet multicast.
* 他のEVPN PE、たとえばPe2が（s、g）に関心があるとします。PE1は、イーサネットのパケットをカプセル化し、SBDにPE1のMACアドレスをMAC SAフィールドに記入します。PE1は、パケットをPE2にトンネルします。トンネルのカプセル化は、見かけのソースBDをSBDとして識別します。見かけのソースBDはSBDであるため、PE2はフレームをサブネット間マルチキャストとして扱うことを知っています。
When IR is used to transmit IP multicast frames from an ingress EVPN PE to a set of egress PEs, then the ingress PE has to send multiple copies of the frame. Each copy is the original Ethernet frame; decapsulation and IP processing take place only at the egress PE.
IRを使用してIPマルチキャストフレームをイングレスEVPN PEから出力PEのセットに送信すると、イングレスPEはフレームの複数のコピーを送信する必要があります。各コピーは元のイーサネットフレームです。脱カプセル化とIP処理は、出口PEでのみ行われます。
If a P2MP tree or Bit Index Explicit Replication (BIER) [RFC9624] is used to transmit an IP multicast frame from an ingress PE to a set of egress PEs, then the ingress PE only has to send one copy of the frame to each of its next hops. Again, each egress PE receives the original frame and does any necessary IP processing.
P2MPツリーまたはビットインデックス明示的複製（BIER）[RFC9624]を使用して、IPマルチキャストフレームを侵入PEから出力PEのセットに送信する場合、侵入PEはフレームのコピーをそれぞれに送信するだけで済みます。その次のホップ。繰り返しますが、各出口PEは元のフレームを受け取り、必要なIP処理を行います。
The model described in Section 1.5.2 can be expressed more precisely using the notion of IRB interface (see Appendix A). For a given Tenant Domain:
セクション1.5.2で説明するモデルは、IRBインターフェイスの概念をより正確に表現できます（付録Aを参照）。特定のテナントドメインの場合：
* A given PE has one IRB interface for each BD to which it is attached. This IRB interface connects L3 routing to that BD. When IP multicast packets are sent or received on the IRB interfaces, the semantics of the interface are modified from the semantics described in Appendix A. See Section 2.3 for the details of the modification.
* 与えられたPEには、BDが取り付けられている各BDに1つのIRBインターフェイスがあります。このIRBインターフェイスは、L3ルーティングをそのBDに接続します。IPマルチキャストパケットがIRBインターフェイスで送信または受信されると、インターフェイスのセマンティクスは、付録Aで説明したセマンティクスから変更されます。修正の詳細については、セクション2.3を参照してください。
* Each PE also has an IRB interface that connects L3 routing to the SBD. The semantics of this interface is different than the semantics of the IRB interface to the real BDs. See Section 2.3.
* 各PEには、L3ルーティングをANDに接続するIRBインターフェイスもあります。このインターフェイスのセマンティクスは、実際のBDSに対するIRBインターフェイスのセマンティクスとは異なります。セクション2.3を参照してください。
In this section, we assume that PIM is not enabled on the IRB interfaces. In general, it is not necessary to enable PIM on the IRB interfaces unless there are PIM routers on one of the Tenant Domain's BDs or there is some other scenario requiring a Tenant Domain's L3 routing instance to become a PIM adjacency of some other system. These cases will be discussed in Section 7.
このセクションでは、PIMがIRBインターフェイスで有効になっていないと仮定します。一般に、テナントドメインのBDの1つにPIMルーターがある場合を除き、Tenant DomainのL3ルーティングインスタンスが他のシステムのPIM隣接になる必要がある他のシナリオがない限り、IRBインターフェイスでPIMを有効にする必要はありません。これらのケースについては、セクション7で説明します。
Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3) and two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.
特定のテナントドメインに3つのBD（BD1、BD2、およびBD3）と2つのPES（PE1およびPE2）が含まれているとします。PE1はBD1とBD2に付着し、PE2はBD2とBD3に付着します。
To carry out the procedures described above, all the PEs attached to the Tenant Domain must be provisioned with the SBD for that Tenant Domain. An RT must be associated with the SBD and provisioned on each of those PEs. We will refer to that RT as the "SBD-RT".
上記の手順を実行するには、テナントドメインに接続されたすべてのPESをそのテナントドメインのSBDでプロビジョニングする必要があります。RTはSBDに関連付けられ、それらの各PEでプロビジョニングされている必要があります。そのRTを「SBD-RT」と呼びます。
A Tenant Domain is also configured with an IP-VRF [RFC9135], and the IP-VRF is associated with an RT. This RT MAY be the same as the SBD-RT.
テナントドメインもIP-VRF [RFC9135]で構成され、IP-VRFはRTに関連付けられています。このRTは、SBD-RTと同じかもしれません。
Suppose an (S,G) multicast frame originating on BD1 has a receiver on BD3. PE1 will transmit the packet to PE2 as a frame, and the encapsulation will identify the frame's source BD as BD1. Since PE2 is not provisioned with BD1, it will treat the packet as if its source BD were the SBD. That is, a packet can be transmitted from BD1 to BD3 even though its ingress PE is not configured for BD3 and/ or its egress PE is not configured for BD1.
BD1に由来する（s、g）マルチキャストフレームがBD3にレシーバーを持っているとします。PE1はパケットをフレームとしてPE2に送信し、カプセル化はフレームのソースBDをBD1として識別します。PE2はBD1でプロビジョニングされていないため、ソースBDがSBDであるかのようにパケットを扱います。つまり、侵入PEがBD3に構成されていない場合でも、パケットをBD1からBD3に送信できます。
EVPN supports service models in which a given EVI can contain only one BD. It also supports service models in which a given EVI can contain multiple BDs. No matter which service model is being used for a particular tenant, it is highly RECOMMENDED that an EVI containing only the SBD be provisioned for that tenant.
EVPNは、特定のEVIに1つのBDのみを含めることができるサービスモデルをサポートしています。また、特定のEVIに複数のBDを含めることができるサービスモデルもサポートしています。どのサービスモデルが特定のテナントに使用されていても、SBDのみを含むEVIをそのテナントに提供することを強くお勧めします。
If, for some reason, it is not feasible to provision an EVI that contains only the SBD, it is possible to put the SBD in an EVI that contains other BDs. However, in that case, the SBD-RT MUST be different than the RT associated with any other BD. Otherwise, the procedures of this document (as detailed in Sections 2.2 and 3.1) will not produce correct results.
何らかの理由で、SBDのみを含むEVIをプロビジョニングすることが不可能な場合、SBDを他のBDを含むEVIに入れることができます。ただし、その場合、SBD-RTは、他のBDに関連付けられたRTとは異なる必要があります。それ以外の場合、このドキュメントの手順（セクション2.2および3.1で詳細）では、正しい結果が得られません。
In this document, we frequently say that a particular multicast route is "from" or "for" a particular BD or is "related to" or "associated with" a particular BD. These terms are used interchangeably. Subsequent sections of this document explain when various routes must be originated for particular BDs. In this section, we explain how the PE originating a route marks the route to indicate which BD it is for. We also explain how a PE receiving the route determines which BD the route is for.
このドキュメントでは、特定のマルチキャストルートは、特定のBDの「または」または「関連」または「関連」であると頻繁に言います。これらの用語は同じ意味で使用されます。このドキュメントの次のセクションでは、特定のBDSに対してさまざまなルートを発信する必要がある場合を説明します。このセクションでは、ルートを発信するPEがルートをマークして、どのBDのためのルートを示すかを説明します。また、ルートを受け取るPEがどのようにルートの目的を決定するかを説明します。
In EVPN, each BD is assigned an RT. An RT is a BGP Extended Community that can be attached to the BGP routes used by the EVPN control plane. In some EVPN service models, each BD is assigned a unique RT. In other service models, a set of BDs (all in the same EVI) may be assigned the same RT. The RT that is assigned to the SBD is called the "SBD-RT".
EVPNでは、各BDにRTが割り当てられます。RTは、EVPNコントロールプレーンが使用するBGPルートに接続できるBGP拡張コミュニティです。一部のEVPNサービスモデルでは、各BDに一意のRTが割り当てられます。他のサービスモデルでは、一連のBDS（すべて同じEVI）に同じRTが割り当てられます。SBDに割り当てられたRTは、「SBD-RT」と呼ばれます。
In those service models that allow a set of BDs to share a single RT, each BD is assigned a non-zero Tag ID. The Tag ID appears in the Network Layer Reachability Information (NLRI) of many of the BGP routes that are used by the EVPN control plane.
BDのセットが単一のRTを共有できるようにするサービスモデルでは、各BDにはゼロ以外のタグIDが割り当てられます。タグIDは、EVPNコントロールプレーンで使用されている多くのBGPルートのネットワークレイヤーリーチ可能性情報（NLRI）に表示されます。
A given route may be for the SBD or an ordinary BD (a BD that is not the SBD). An RT that has been assigned to an ordinary BD will be known as an "ordinary BD-RT".
特定のルートは、SBDまたは通常のBD（SBDではないBD）用です。通常のBDに割り当てられたRTは、「通常のBD-RT」として知られています。
When constructing an IMET, SMET, S-PMSI, or Leaf [RFC9572] route that is for a given BD, the following rules apply:
IMET、SMET、S-PMSI、またはLEAF [RFC9572]ルートを構築する場合、特定のBD用のルートは、次のルールが適用されます。
* If the route is for an ordinary BD, say BD1, then:
* ルートが通常のBD用である場合は、BD1と言います。
- the route MUST carry the ordinary BD-RT associated with BD1 and
- ルートは、BD1に関連する通常のBD-RTを運ぶ必要があり、
- the route MUST NOT carry any RT that is associated with an ordinary BD other than BD1.
- ルートは、BD1以外の通常のBDに関連付けられているRTを搭載してはなりません。
* If the route is for the SBD, the route MUST carry the SBD-RT and MUST NOT carry any RT that is associated with any other BD.
* ルートがANDの場合、ルートはSBD-RTを運ぶ必要があり、他のBDに関連付けられているRTを搭載してはなりません。
* As detailed in subsequent sections, under certain circumstances, a route that is for BD1 may carry both the RT of BD1 and also the SBD-RT.
* 後続のセクションで詳述されているように、特定の状況では、BD1向けのルートは、BD1のRTとSBD-RTの両方を運ぶことができます。
The IMET route for the SBD MUST carry a Multicast Flags Extended Community in which an OISM SBD flag is set.
SBDのIMETルートは、OISM SBDフラグが設定されているマルチキャストフラグ拡張コミュニティを搭載する必要があります。
The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC as defined in [RFC9251]. The EC is constructed from the SBD-RT to indicate the BD's corresponding SBD. This allows all PEs to check that they have consistent SBD provisioning and allows an Assisted Replication (AR) replicator to automatically determine a BD's corresponding SBD without any provisioning, as explained in Section 3.2.3.1.
SBD以外のBDのIMETルートは、[RFC9251]で定義されているようにEVI-RT ECを運ぶ必要があります。ECは、BDに対応するSBDを示すためにSBD-RTから構築されています。これにより、すべてのPEが一貫したSBDプロビジョニングを備えていることを確認し、セクション3.2.3.1で説明するように、プロビジョニングなしでBDの対応するSBDを自動的に決定できるように支援レプリケーター（AR）レプリケーターが可能になります。
When receiving an IMET, SMET, S-PMSI, or Leaf route, it is necessary for the receiving PE to determine the BD to which the route belongs. This is done by examining the RTs carried by the route, as well as the Tag ID field of the route's NLRI. There are several cases to consider. Some of these cases are error cases that arise when the route has not been properly constructed.
IMET、SMET、S-PMSI、またはリーフルートを受信する場合、受信PEがルートが属するBDを決定する必要があります。これは、ルートで運ばれるRTとルートのNLRIのタグIDフィールドを調べることによって行われます。考慮すべきいくつかのケースがあります。これらのケースの一部は、ルートが適切に構築されていないときに発生するエラーケースです。
When one of the error cases is detected, the route MUST be regarded as a malformed route, and the treat-as-withdraw procedure of [RFC7606] MUST be applied. Note that these error cases are only detectable by EVPN procedures at the receiving PE; BGP procedures at intermediate nodes will generally not detect the existence of such error cases and in general SHOULD NOT attempt to do so.
エラーケースの1つが検出された場合、ルートは奇形のルートと見なされ、[RFC7606]の扱いやすい手順を適用する必要があります。これらのエラーケースは、受信PEでのEVPN手順によってのみ検出可能であることに注意してください。中間ノードでのBGP手順は、一般にそのようなエラーケースの存在を検出せず、一般にそうすることを試みるべきではありません。
Case 1: The receiving PE recognizes more than one of the route's RTs as being an SBD-RT (i.e., the route carries SBD-RTs of more than one Tenant Domain).
ケース1：受信PEは、ルートのRTの複数をSBD-RTであると認識しています（つまり、ルートには複数のテナントドメインのSBD-RTが含まれています）。
This is an error case; the route has not been properly constructed.
これはエラーケースです。ルートは適切に構築されていません。
Case 2: The receiving PE recognizes one of the route's RTs as being associated with an ordinary BD and recognizes one of the route's other RTs as being associated with a different ordinary BD.
ケース2：受信PEは、ルートのRTの1つが通常のBDに関連付けられていると認識し、ルートの他のRTの1つを異なる通常のBDに関連付けていることを認識します。
This is an error case; the route has not been properly constructed.
これはエラーケースです。ルートは適切に構築されていません。
Case 3: The receiving PE recognizes one of the route's RTs as being associated with an ordinary BD in a particular Tenant Domain and recognizes another of the route's RTs as being associated with the SBD of a different Tenant Domain.
ケース3：受信PEは、ルートのRTの1つが特定のテナントドメインの通常のBDに関連付けられていると認識し、別のテナントドメインのSBDに関連付けられているルートのRTの別のRTを認識します。
This is an error case; the route has not been properly constructed.
これはエラーケースです。ルートは適切に構築されていません。
Case 4: The receiving PE does not recognize any of the route's RTs as being associated with an ordinary BD in any of its Tenant Domains but does recognize one of the RTs as the SBD-RT of one of its Tenant Domains.
ケース4：受信PEは、ルートのRTのいずれも、テナントドメインのいずれかの通常のBDに関連付けられていると認識していませんが、RTの1つをテナントドメインの1つのSBD-RTとして認識しています。
In this case, the receiving PE associates the route with the SBD of that Tenant Domain. This association is made even if the Tag ID field of the route's NLRI is not the Tag ID of the SBD.
この場合、受信PEはルートをそのテナントドメインのSBDに関連付けます。この関連付けは、ルートのNLRIのタグIDフィールドがSBDのタグIDではない場合でも行われます。
This is a normal use case where either (a) the route is for a BD to which the receiving PE is not attached or (b) the route is for the SBD. In either case, the receiving PE associates the route with the SBD.
これは、（a）ルートが受信PEが添付されていないBD用、または（b）ルートがSBD用である場合の通常のユースケースです。どちらの場合でも、受信PEはルートをSBDに関連付けます。
Case 5: The receiving PE recognizes exactly one of the RTs as an ordinary BD-RT that is associated with one of the PE's EVIs, say EVI-1. The receiving PE also recognizes one of the RTs as being the SBD-RT of the Tenant Domain containing EVI-1.
ケース5：受信PEは、RTの1つを、PEのEVIの1つに関連付けられている通常のBD-RTとして正確に認識しています。受信PEは、RTの1つがEVI-1を含むテナントドメインのSBD-RTであると認識しています。
In this case, the route is associated with the BD in EVI-1 that is identified (in the context of EVI-1) by the Tag ID field of the route's NLRI. (If EVI-1 contains only a single BD, the Tag ID is likely to be zero.)
この場合、ルートは、ルートのNLRIのタグIDフィールドによって（EVI-1のコンテキストで）識別されるEVI-1のBDに関連付けられています。（EVI-1に単一のBDのみが含まれている場合、タグIDはゼロになる可能性があります。）
This is the case where the route is for a BD to which the receiving PE is attached, but the route also carries the SBD-RT. In this case, the receiving PE associates the route with the ordinary BD, not with the SBD.
これは、ルートが受信PEが接続されているBDの場合ですが、ルートにはSBD-RTも含まれています。この場合、受信PEは、SBDではなく、通常のBDにルートを関連付けます。
Note that according to the above rules, the mapping from BD to RT is a many-to-one or one-to-one mapping. A route that an EVPN PE originates for a particular BD carries that BD's RT, and an EVPN PE that receives the route associates it with a BD as described above. However, RTs are not used only to help identify the BD to which a route belongs; they may also be used by BGP to determine the path along which the route is distributed and to determine which PEs receive the route. There may be cases where it is desirable to originate a route for a particular BD but have that route distributed to only some of the EVPN PEs attached to that BD. Or one might want the route distributed to some intermediate set of systems, where it might be modified or replaced before being propagated further. Such situations are outside the scope of this document.
上記のルールによれば、BDからRTへのマッピングは、多面または1対1のマッピングであることに注意してください。特定のBDのEVPN PEが発生するルートは、そのBDのRTと、上記のようにそれをBDに関連付けるルートを受信するEVPN PEを伝えます。ただし、RTは、ルートが属するBDを特定するのに役立つためだけに使用されません。また、BGPによって使用されて、ルートが分散されるパスを決定し、どのPEがルートを受信するかを決定することもできます。特定のBDのルートを発信することが望ましい場合がありますが、そのルートは、そのBDに接続されているEVPN PEの一部のみに分配されます。または、ルートを中間のシステムセットに配布することを望むかもしれません。このセットでは、さらに伝播する前に変更または交換される可能性があります。このような状況は、このドキュメントの範囲外です。
Additionally, there may be situations where it is desirable to exchange routes among two or more different Tenant Domains (EVPN Extranet). Such situations are outside the scope of this document.
さらに、2つ以上の異なるテナントドメイン（EVPNエクストラネット）間でルートを交換することが望ましい状況がある場合があります。このような状況は、このドキュメントの範囲外です。
When an (S,G) multicast frame is received from an AC belonging to a particular BD, say BD1:
（s、g）マルチキャストフレームが特定のBDに属するACから受信される場合、たとえばBD1：
1. The frame is sent unchanged to other EVPN PEs that are interested in (S,G) traffic. The encapsulation used to send the frame to the other EVPN PEs depends on the tunnel type being used for multicast transmission. (For our purposes, we consider IR, AR, and BIER to be tunnel types, even though IR, AR, and BIER do not actually use P2MP tunnels.) At the egress PE, the apparent source BD of the frame can be inferred from the tunnel encapsulation. If the egress PE is not attached to the actual source BD, it will infer that the apparent source BD is the SBD.
1. フレームは、（s、g）トラフィックに関心のある他のevpn pesに変換されずに送信されます。フレームを他のEVPN PEに送信するために使用されるカプセル化は、マルチキャスト伝送に使用されているトンネルタイプに依存します。（私たちの目的のために、IR、AR、およびビアは実際にP2MPトンネルを使用していない場合でも、IR、AR、およびビアはトンネルタイプであると考えています。）出口PEでは、フレームの見かけのソースBDをから推測できます。トンネルのカプセル化。出力PEが実際のソースBDに接続されていない場合、見かけのソースBDがSBDであると推測されます。
Note that the inter-PE transmission of a multicast frame among EVPN PEs of the same Tenant Domain does NOT involve the IRB interfaces as long as the multicast frame was received over an AC attached to one of the Tenant Domain's BDs.
同じテナントドメインのEVPN PES間のマルチキャストフレームのInterPE伝送は、テナントドメインのBDSの1つに接続されたACにマルチキャストフレームが受信されている限り、IRBインターフェイスを含むことはないことに注意してください。
2. The frame is also sent up the IRB interface that attaches BD1 to the Tenant Domain's L3 routing instance in this PE. That is, the L3 routing instance, behaving as if it were a multicast router, receives the IP multicast frames that arrive at the PE from its local ACs. The L3 routing instance decapsulates the frame's payload to extract the IP multicast packet, decrements the IP TTL, adjusts the header checksum, and does any other necessary IP processing (e.g., fragmentation).
2. フレームは、このPEのテナントドメインのL3ルーティングインスタンスにBD1を取り付けるIRBインターフェイスにも送信されます。つまり、L3ルーティングインスタンスは、まるでマルチキャストルーターであるかのように動作し、ローカルACSからPEに到達するIPマルチキャストフレームを受信します。L3ルーティングインスタンスは、フレームのペイロードを脱カプセル化してIPマルチキャストパケットを抽出し、IP TTLを減らし、ヘッダーチェックサムを調整し、他の必要なIP処理（例：断片化）を行います。
3. The L3 routing instance keeps track of which BDs have local receivers for (S,G) traffic. (A local receiver is a TS, reachable via a local AC, that has expressed interest in (S,G) traffic.) If the L3 routing instance has an IRB interface to BD2, and it knows that BD2 has a LOCAL receiver interested in (S,G) traffic, it encapsulates the packet in an Ethernet header for BD2, putting its own MAC address in the MAC SA field. Then, it sends the packet down the IRB interface to BD2.
3. L3ルーティングインスタンスは、BDSが（S、G）トラフィックのローカルレシーバーを持っていることを追跡します。（ローカルレシーバーはTSであり、ローカルACを介して到達可能です。これは（S、G）トラフィックに関心を示しています。）L3ルーティングインスタンスにBD2へのIRBインターフェイスがあり、BD2にはローカルレシーバーが関心のあるローカルレシーバーがあることがわかっています。（S、G）トラフィック、BD2のイーサネットヘッダーのパケットをカプセル化し、Mac SAフィールドに独自のMACアドレスを配置します。次に、IRBインターフェイスからパケットをBD2に送信します。
If a packet is sent from the L3 routing instance to a particular BD via the IRB interface (step 3 in the above list), and if the BD in question is NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If the packet needs to go to other PEs, it has already been sent to them in step 1. Note that this is a change in the IRB interface semantics from what is described in [RFC9135] and Figure 3.
パケットがL3ルーティングインスタンスからIRBインターフェイスを介して特定のBDに送信された場合（上記のリストのステップ3）、問題のBDがSBDではない場合、パケットはそのBDのローカルACにのみ送信されます。パケットが他のPESに移動する必要がある場合、ステップ1ですでにそれらに送信されています。これは、[RFC9135]および図3で説明されているものからのIRBインターフェイスセマンティクスの変更であることに注意してください。
If a given locally attached segment is multihomed, existing EVPN procedures ensure that a packet is not sent by a given PE to that segment unless the PE is the DF for that segment. Those procedures also ensure that a packet is never sent by a PE to its segment of origin. Thus, EVPN segment multihoming is fully supported; duplicate delivery to a segment or looping on a segment are thereby prevented without the need for any new procedures to be defined in this document.
特定の局所的に添付されたセグメントがマルチホームである場合、既存のEVPN手順により、PEがそのセグメントのDFでない限り、特定のPEによって特定のPEによってそのセグメントに送信されないようにします。また、これらの手順では、パケットがPEによってOriginのセグメントに送信されないようにします。したがって、EVPNセグメントマルチホミングは完全にサポートされています。セグメントへの重複またはセグメントでのループを重複させることは、このドキュメントで新しい手順を定義する必要なく、防止されます。
What if an IP multicast packet is received from outside the Tenant Domain? For instance, perhaps PE1's IP-VRF for a particular Tenant Domain also has a physical interface leading to an external switch, host, or router and PE1 receives an IP multicast packet or frame on that interface, or perhaps the packet is from an L3VPN or a different EVPN Tenant Domain.
IPマルチキャストパケットがテナントドメインの外部から受信された場合はどうなりますか？たとえば、おそらく特定のテナントドメインのPE1のIP-VRFには、外部スイッチ、ホスト、またはルーターにつながる物理インターフェイスもあり、PE1はそのインターフェイスにIPマルチキャストパケットまたはフレームを受け取ります。別のEVPNテナントドメイン。
Such a packet is first processed by the L3 routing instance, which decrements TTL and does any other necessary IP processing. Then, the packet is sent into the Tenant Domain by sending it down the IRB interface to the SBD of that Tenant Domain. This requires encapsulating the packet in an Ethernet header. The MAC SA field will contain the PE's own MAC on the SBD.
このようなパケットは、最初にL3ルーティングインスタンスによって処理され、TTLを減少させ、他の必要なIP処理を行います。次に、IRBインターフェイスをそのテナントドメインのSBDに送信することにより、パケットがテナントドメインに送信されます。これには、イーサネットヘッダーのパケットをカプセル化する必要があります。Mac SAフィールドには、SBDにPE独自のMacが含まれます。
An IP multicast packet sent by the L3 routing instance down the IRB interface to the SBD is treated as if it had arrived from a local AC, and steps 1-3 are applied. Note that the semantics of sending a packet down the IRB interface to the SBD are thus slightly different than the semantics of sending a packet down other IRB interfaces. IP multicast packets sent down the SBD's IRB interface may be distributed to other PEs, but IP multicast packets sent down other IRB interfaces are distributed only to local ACs.
L3ルーティングインスタンスによってIRBインターフェイスをSBDに送信したIPマルチキャストパケットは、ローカルACから到着したかのように扱われ、ステップ1-3が適用されます。したがって、IRBインターフェイスをSBDにパケットを送信するセマンティクスは、他のIRBインターフェイスをパケットを送信するセマンティクスとはわずかに異なることに注意してください。SBDのIRBインターフェイスを送信したIPマルチキャストパケットは、他のPESに配布される場合がありますが、他のIRBインターフェイスが送信されるIPマルチキャストパケットは、ローカルACSにのみ配布されます。
If a PE sends a link-local multicast packet down the SBD IRB interface, that packet will be distributed (as an Ethernet frame) to other PEs of the Tenant Domain but will not appear on any of the actual BDs.
PEがLink-Local MulticastパケットをSBD IRBインターフェイスに送信する場合、そのパケットは（イーサネットフレームとして）テナントドメインの他のPEに分散されますが、実際のBDSのいずれにも表示されません。
Suppose an egress EVPN PE receives an (S,G) multicast frame from the frame's ingress EVPN PE. As described above, the packet will arrive as an Ethernet frame over a tunnel from the ingress PE, and the tunnel encapsulation will identify the source BD of the Ethernet frame.
出口evpn PEがフレームの侵入EVPN PEから（s、g）マルチキャストフレームを受け取るとします。上記のように、パケットは侵入PEからのトンネル上のイーサネットフレームとして到着し、トンネルのカプセル化はイーサネットフレームのソースBDを識別します。
We define the notion of the frame's apparent source BD as follows. If the egress PE is attached to the actual source BD, the actual source BD is the apparent source BD. If the egress PE is not attached to the actual source BD, the SBD is the apparent source BD.
フレームの見かけのソースBDの概念を次のように定義します。出力PEが実際のソースBDに接続されている場合、実際のソースBDは見かけのソースBDです。出口PEが実際のソースBDに接続されていない場合、SBDは見かけのソースBDです。
The egress PE now takes the following steps:
出力PEは今、次の手順を講じます。
1. If the egress PE has ACs belonging to the apparent source BD of the frame, it sends the frame unchanged to any ACs of that BD that have interest in (S,G) packets. The MAC SA of the frame is not modified, and the IP header of the frame's payload is not modified in any way.
1. 出口PEにフレームの見かけのソースBDに属するACSがある場合、（s、g）パケットに興味のあるBDのACSに変更されていないフレームを送信します。フレームのMac SAは変更されておらず、フレームのペイロードのIPヘッダーは決して変更されていません。
2. The frame is also sent to the L3 routing instance by being sent up the IRB interface that attaches the L3 routing instance to the apparent source BD. Steps 2 and 3 listed in Section 2.3 are then applied.
2. フレームは、L3ルーティングインスタンスを見かけのソースBDに接続するIRBインターフェイスを送信することにより、L3ルーティングインスタンスにも送信されます。次に、セクション2.3にリストされている手順2と3が適用されます。
[RFC9251] defines procedures used by an egress PE to announce its interest in a multicast flow or set of flows. If an egress PE determines it has LOCAL receivers in a particular BD, say BD1, that are interested in a particular set of flows, it originates one or more SMET routes for BD1. Each SMET route specifies a particular (S,G) or (*,G) flow. By originating a SMET route for BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in BD1". Such a SMET route carries the RT for BD1, ensuring that it will be distributed to all PEs that are attached to BD1.
[RFC9251]出力PEが使用する手順を定義して、マルチキャストフローまたはフローセットへの関心を発表します。Egress PEが特定のBD、たとえばBD1にローカルレシーバーがあると判断した場合、特定のフローセットに興味がある場合、BD1の1つ以上のSMETルートが発生します。各SMETルートは、特定の（s、g）または（*、g）フローを指定します。BD1のSMETルートを発信することにより、PEは「BD1の（s、g）または（*、g）のレシーバーがある」と発表しています。このようなSMETルートには、BD1のRTが搭載されており、BD1に接続されているすべてのPESに分布するようにします。
The OISM procedures for originating SMET routes differ slightly from those in [RFC9251]. In most cases, the SMET routes are considered to be for the SBD rather than the BD containing local receivers. These SMET routes carry the SBD-RT and do not carry any ordinary BD-RT. Details on the processing of SMET routes can be found in Section 3.3.
SMETルートを発信するOISM手順は、[rfc9251]の路線とはわずかに異なります。ほとんどの場合、SMETルートは、ローカルレシーバーを含むBDではなく、SBD用であると考えられています。これらのSMETルートはSBD-RTを運び、通常のBD-RTを搭載していません。SMETルートの処理に関する詳細は、セクション3.3にあります。
Since the SMET routes carry the SBD-RT, every ingress PE attached to a particular Tenant Domain will learn of all other PEs (attached to the same Tenant Domain) that have interest in a particular set of flows. Note that a PE that receives a given SMET route does not necessarily have any BDs (other than the SBD) in common with the PE that originates that SMET route.
SMETルートにはSBD-RTが含まれているため、特定のテナントドメインに取り付けられたすべての侵入PEは、特定のフローセットに関心のある他のすべてのPE（同じテナントドメインに取り付けられている）について学びます。特定のSMETルートを受け取るPEには、そのSMETルートを発生するPEと共通するBDS（SBD以外）は必ずしもないことに注意してください。
If all the sources and receivers for a given (*,G) are in the Tenant Domain, inter-subnet ASM traffic will be properly routed without requiring any RPs, shared trees, or other complex aspects of multicast routing infrastructure. Suppose, for example, that:
特定のソースと特定のソース（*、g）がテナントドメインにある場合、マルチキャストルーティングインフラストラクチャのRP、共有ツリー、またはその他の複雑な側面を必要とせずに、サブネット間のASMトラフィックが適切にルーティングされます。たとえば、それをとってください：
* PE1 has a local receiver, on BD1, for (*,G) and
* PE1には、BD1に（*、g）のローカルレシーバーがあり、
* PE2 has a local source, on BD2, for (*,G).
* PE2には、（*、g）のbd2にローカルソースがあります。
PE1 will originate a SMET(*,G) route for the SBD, and PE2 will receive that route, even if PE2 is not attached to BD1. PE2 will thus know to forward (S,G) traffic to PE1. PE1 does not need to do any source discovery. (This does assume that source S does not send the same (S,G) datagram on two different BDs and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP anycast addresses is outside the scope of this document.)
PE1はSBDのSMET（*、G）ルートを発生し、PE2がBD1に接続されていなくても、PE2はそのルートを受け取ります。したがって、PE2はPE1へのトラフィックを転送することを知っています。PE1は、ソースの発見を行う必要はありません。（これは、ソースSが2つの異なるBDSで同じ（s、g）データグラムを送信せず、テナントドメインには同じIPアドレスSの2つ以上のソースが含まれていないと仮定します。アドレスは、このドキュメントの範囲外です。）
If some PE attached to the Tenant Domain does not support [RFC9251], it will be assumed to be interested in all flows. Whether a particular remote PE supports [RFC9251] or not is determined by the presence of the Multicast Flags Extended Community in its IMET route; this is specified in [RFC9251].
テナントドメインに接続されているPEが[RFC9251]をサポートしていない場合、すべてのフローに関心があると想定されます。特定のリモートPEが[RFC9251]をサポートするかどうかは、IMETルートにマルチキャストフラグ拡張コミュニティが存在することによって決定されます。これは[RFC9251]で指定されています。
[RFC7432] specifies the procedures for setting up and using BUM tunnels. A BUM tunnel is a tunnel used to carry traffic on a particular BD if that traffic is (a) broadcast traffic, (b) unicast traffic with an unknown Destination MAC Address, or (c) Ethernet multicast traffic.
[RFC7432]は、バムトンネルをセットアップおよび使用する手順を指定します。Bumトンネルは、そのトラフィックが（a）放送トラフィック、（b）未知の宛先MACアドレスを備えたユニキャストトラフィック、または（c）イーサネットマルチキャストトラフィックの場合、特定のBDのトラフィックを運ぶために使用されるトンネルです。
This document allows the BUM tunnels to be used as the default tunnels for transmitting IP multicast frames. It also allows a separate set of tunnels to be used, instead of the BUM tunnels, as the default tunnels for carrying IP multicast frames. Let's call these "IP multicast tunnels".
このドキュメントにより、IPマルチキャストフレームを送信するためのデフォルトのトンネルとして、バムトンネルを使用できます。また、IPマルチキャストフレームを搭載するためのデフォルトのトンネルとして、Bumトンネルの代わりに、個別のトンネルセットを使用できます。これらを「IPマルチキャストトンネル」と呼びましょう。
When the tunneling is done via IR or via BIER, this difference is of no significance. However, when P2MP tunnels are used, there is a significant advantage to having separate IP multicast tunnels.
トンネリングがIRまたはBierを介して行われる場合、この違いは重要ではありません。ただし、P2MPトンネルを使用する場合、IPマルチキャストトンネルを別々にすることには大きな利点があります。
It is desirable for an ingress PE to transmit a copy of a given (S,G) multicast frame on only one P2MP tunnel. All egress PEs interested in (S,G) packets then have to join that tunnel. If the source BD and PE for an (S,G) frame are BD1 and PE1, respectively, and if PE2 has receivers on BD2 for (S,G), then PE2 must join the P2MP Label Switched Path (LSP) on which PE1 transmits the (S,G) frame. PE2 must join this P2MP LSP even if PE2 is not attached to the source BD, BD1. If PE1 was transmitting the multicast frame on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM tunnel, even though PE2 has no BD1 Attachment Circuits. This would cause PE2 to pull all the BUM traffic from BD1, most of which it would just have to discard. Thus, it is RECOMMENDED that the default IP multicast tunnels be distinct from the BUM tunnels.
Ingress PEが1つのP2MPトンネルのみに与えられた（s、g）マルチキャストフレームのコピーを送信することが望ましいです。（s、g）パケットに関心のあるすべての出力pesは、そのトンネルに結合する必要があります。（s、g）フレームのソースBDとPEがそれぞれBD1とPE1であり、PE2が（S、G）に対してBD2の受信機を持っている場合、PE2はPE1のP2MPラベルスイッチドパス（LSP）に結合する必要があります。（s、g）フレームを送信します。PE2がソースBD、BD1に接続されていない場合でも、PE2はこのP2MP LSPに参加する必要があります。PE1がBD1バムトンネルにマルチキャストフレームを送信していた場合、PE2にはBD1アタッチメント回路がない場合でも、PE2はBD1バムトンネルに参加する必要があります。これにより、PE2はBD1からすべてのバムトラフィックを引き出し、そのほとんどは廃棄する必要があります。したがって、デフォルトのIPマルチキャストトンネルは、バムトンネルとは異なることをお勧めします。
Notwithstanding the above, link-local IP multicast traffic MUST always be carried on the BUM tunnels and ONLY on the BUM tunnels. Link-local IP multicast traffic consists of IPv4 traffic with a destination address prefix of 224/24 and IPv6 traffic with a destination address prefix of FF02/16. In this document, the terms "IP multicast packet" and "IP multicast frame" are defined in Section 1.1 so as to exclude link-local traffic.
上記にもかかわらず、Link-Local IPマルチキャストトラフィックは、常にBumトンネルで、そしてBumトンネルでのみ持ち運ぶ必要があります。Link-Local IPマルチキャストトラフィックは、224/24の宛先アドレスプレフィックスを備えたIPv4トラフィックと、FF02/16の宛先アドレスプレフィックスを備えたIPv6トラフィックで構成されています。このドキュメントでは、「IPマルチキャストパケット」と「IPマルチキャストフレーム」という用語は、リンクローカルトラフィックを除外するためにセクション1.1で定義されています。
Note that it is also possible to use selective tunnels to carry particular multicast flows (see Section 3.2). When an (S,G) frame is transmitted on a selective tunnel, it is not transmitted on the BUM tunnel or on the default IP multicast tunnel.
選択的なトンネルを使用して特定のマルチキャストフローを運ぶことも可能であることに注意してください（セクション3.2を参照）。（s、g）フレームが選択的トンネルに送信されると、バムトンネルまたはデフォルトのIPマルチキャストトンネルに送信されません。
There are some deployment scenarios that require special procedures:
特別な手順を必要とするいくつかの展開シナリオがあります。
1. Some multicast sources or receivers are attached to PEs that support [RFC7432] but do not support this document or [RFC9135]. To interoperate with these non-OISM PEs, it is necessary to have one or more gateway PEs that interface the tunnels discussed in this document with the BUM tunnels of the legacy PEs. This is discussed in Section 5.
1. 一部のマルチキャストソースまたは受信機は、[RFC7432]がこのドキュメントまたは[RFC9135]をサポートしていないPESに接続されています。これらの非オイズムPEと相互運用するには、このドキュメントで議論されたトンネルとレガシーPESのバムトンネルとインターフェイスする1つ以上のゲートウェイPEを使用する必要があります。これについては、セクション5で説明します。
2. Sometimes multicast traffic originates from outside the EVPN domain or needs to be sent outside the EVPN domain. This is discussed in Section 6. An important special case of this, integration with MVPN, is discussed in Section 6.1.2.
2. マルチキャストトラフィックがEVPNドメインの外側から発生したり、EVPNドメインの外側に送信する必要がある場合があります。これについては、セクション6で説明します。これの重要な特別なケース、MVPNとの統合については、セクション6.1.2で説明します。
3. In some scenarios, one or more of the tenant systems is a PIM router, and the Tenant Domain is used as a transit network that is part of a larger multicast domain. This is discussed in Section 7.
3. 一部のシナリオでは、1つ以上のテナントシステムがPIMルーターであり、テナントドメインは、より大きなマルチキャストドメインの一部であるトランジットネットワークとして使用されます。これについては、セクション7で説明します。
As discussed in Section 2.1, every Tenant Domain is associated with a single SBD. Recall that a Tenant Domain is defined to be a set of BDs that can freely send and receive IP multicast traffic to/from each other. If an EVPN PE has one or more ACs in a BD of a particular Tenant Domain, and if the EVPN PE supports the procedures of this document, that EVPN PE MUST be provisioned with the SBD of that Tenant Domain.
セクション2.1で説明したように、すべてのテナントドメインは単一のSBDに関連付けられています。テナントドメインは、IPマルチキャストトラフィックを互いに自由に送信および受信できるBDのセットであると定義されていることを思い出してください。EVPN PEが特定のテナントドメインのBDに1つ以上のACSを持ち、EVPN PEがこのドキュメントの手順をサポートしている場合、そのEVPN PEをそのテナントドメインのSBDでプロビジョニングする必要があります。
At each EVPN PE attached to a given Tenant Domain, there is an IRB interface leading from the L3 routing instance of that Tenant Domain to the SBD. However, the SBD has no ACs.
特定のテナントドメインに接続された各EVPN PEに、そのテナントドメインのL3ルーティングインスタンスからSBDへのIRBインターフェイスがあります。ただし、SBDにはACSがありません。
Each SBD is provisioned with an RT. All the EVPN PEs supporting a given SBD are provisioned with that RT as an import RT. That RT MUST NOT be the same as the RT associated with any other BD.
各SBDにはRTがプロビジョニングされます。特定のSBDをサポートするすべてのEVPN PEは、そのRTをインポートRTとしてプロビジョニングします。そのRTは、他のBDに関連付けられたRTと同じであってはなりません。
We will use the term "SBD-RT" to denote the RT that has been assigned to the SBD. Routes carrying this RT will be propagated to all EVPN PEs in the same Tenant Domain as the originator.
「SBD-RT」という用語を使用して、SBDに割り当てられたRTを示します。このRTを運ぶルートは、オリジネーターと同じテナントドメインのすべてのEVPN PEに伝播されます。
Section 2.2 specifies the rules by which an EVPN PE that receives a route determines whether a received route belongs to a particular ordinary BD or SBD.
セクション2.2は、ルートを受信するEVPN PEが、受信ルートが特定の通常のBDまたはSBDに属するかどうかを決定するルールを指定します。
Section 2.2 also specifies additional rules that must be followed when constructing routes that belong to a particular BD, including the SBD.
セクション2.2は、SBDを含む特定のBDに属するルートを構築するときに従わなければならない追加のルールを指定します。
The SBD SHOULD be in an EVI of its own. Even if the SBD is not in an EVI of its own, the SBD-RT MUST be different than the RT associated with any other BD. This restriction is necessary in order for the rules of Sections 2.2 and 3.1 to work correctly.
SBDは独自のEVIにある必要があります。SBDが独自のEVIにない場合でも、SBD-RTは他のBDに関連付けられたRTとは異なる必要があります。この制限は、セクション2.2および3.1の規則が正しく機能するために必要です。
Note that an SBD, just like any other BD, is associated on each EVPN PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated with a Route Distinguisher (RD). When constructing a route that is for an SBD, an EVPN PE will place the RD of the associated MAC-VRF in the Route Distinguisher field of the NLRI. (If the Tenant Domain has several MAC-VRFs on a given PE, the EVPN PE has a choice of which RD to use.)
SBDは、他のBDと同様に、各EVPN PEにMAC-VRFに関連付けられていることに注意してください。[RFC7432]ごとに、各MAC-VRFはルート違い（RD）に関連付けられています。SBD用のルートを構築する場合、EVPN PEは、NLRIのルート違いフィールドに関連するMAC-VRFのRDを配置します。（テナントドメインに特定のPEにいくつかのMAC-VRFがある場合、EVPN PEにはどのRDを使用するかを選択できます。）
If AR [RFC9574] is used, each AR-REPLICATOR for a given Tenant Domain must be provisioned with the SBD of that Tenant Domain, even if the AR-REPLICATOR does not have any L3 routing instances.
AR [RFC9574]を使用する場合、AR-ReplicatorにL3ルーティングインスタンスがない場合でも、特定のテナントドメインの各ARレプリケーターをそのテナントドメインのSBDにプロビジョニングする必要があります。
The procedures used for advertising the tunnels that carry IP multicast traffic depend upon the type of tunnel being used. If the tunnel type is neither IR, AR, nor BIER, there are procedures for advertising both inclusive tunnels and selective tunnels.
IPマルチキャストトラフィックを運ぶトンネルの宣伝に使用される手順は、使用されているトンネルのタイプに依存します。トンネルタイプがIR、AR、ビアでもない場合、包括的トンネルと選択的トンネルの両方を宣伝する手順があります。
When IR, AR, or BIER are used to transmit IP multicast packets across the core, there are no P2MP tunnels. Once an ingress EVPN PE determines the set of egress EVPN PEs for a given flow, the IMET routes contain all the information needed to transport packets of that flow to the egress PEs.
IR、AR、またはBIERを使用してIPマルチキャストパケットをコアに送信する場合、P2MPトンネルはありません。イングレスEVPN PEが特定のフローの出力EVPN PESのセットを決定すると、IMETルートには、その流れのパケットを出口PESに輸送するために必要なすべての情報が含まれます。
If AR is used, the ingress EVPN PE is also an AR-LEAF, and the IMET route coming from the selected AR-REPLICATOR contains the information needed. The AR-REPLICATOR will behave as an ingress EVPN PE when sending a flow to the egress EVPN PEs.
ARを使用すると、Ingress EVPN PEもARリーフであり、選択したAR-Replicatorから来るIMETルートには必要な情報が含まれています。AR-Replicatorは、出力EVPN PESに流れを送信するときに、侵入EVPN PEとして動作します。
If the tunneling technique requires P2MP tunnels to be set up (e.g., RSVP-TE P2MP, Multipoint LDP (mLDP), or PIM), some of the tunnels may be selective tunnels and some may be inclusive tunnels.
トンネル技術でP2MPトンネルをセットアップする必要がある場合（例：RSVP-TE P2MP、マルチポイントLDP（MLDP）、またはPIM）、トンネルの一部は選択的なトンネルであり、一部は包括的トンネルである場合があります。
Selective P2MP tunnels are always advertised by the ingress PE using S-PMSI Auto-Discovery (A-D) routes [RFC9572].
選択的なP2MPトンネルは、S-PMSIオートディスコービリ（A-D）ルート[RFC9572]を使用して、常に侵入PEによって宣伝されます。
For inclusive tunnels, there is a choice between using a BD's ordinary BUM tunnel as the default inclusive tunnel for carrying IP multicast traffic or using a separate IP multicast tunnel as the default inclusive tunnel for carrying IP multicast. In the former case, the inclusive tunnel is advertised in an IMET route. In the latter case, the inclusive tunnel is advertised in a (C-*,C-*) S-PMSI A-D route [RFC9572]. Details may be found in subsequent sections.
包括的トンネルの場合、IPマルチキャストトラフィックを運ぶためのデフォルトのインクルーシブトンネルとしてBDの通常のBumトンネルを使用するか、IPマルチキャストを運ぶためのデフォルトのIPマルチキャストトンネルを使用するかどうかを選択できます。前者の場合、包括的トンネルはIMETルートで宣伝されています。後者の場合、包括的トンネルは（c - *、c-*）s-pmsi a-dルート[rfc9572]で宣伝されています。詳細は、後続のセクションにあります。
There are situations in which an EVPN PE needs to originate IMET, SMET, and/or S-PMSI routes for the SBD. Throughout this document, we will refer to such routes respectively as "SBD-IMET routes", "SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections detail the conditions under which these routes need to be originated.
EVPN PEがSBDのIMET、SMET、および/またはS-PMSIルートを発信する必要がある状況があります。このドキュメント全体を通して、そのようなルートをそれぞれ「SBD-IMETルート」、「SBD-Smetルート」、および「SBD-SPMSIルート」と呼びます。後続のセクションは、これらのルートを発信する必要がある条件を詳述します。
When an EVPN PE needs to originate an SBD-IMET, SBD-SMET, or SBD-SPMSI route, it constructs the route as follows:
EVPN PEがSBD-IMET、SBD-SMET、またはSBD-SPMSIルートを発信する必要がある場合、次のようにルートを構築します。
* The RD field of the route's NLRI is set to the RD of the MAC-VRF that is associated with the SBD.
* ルートのNLRIのRDフィールドは、SBDに関連付けられているMAC-VRFのRDに設定されています。
* The SBD-RT is attached to the route.
* SBD-RTはルートに接続されています。
* The Tag ID field of the route's NLRI is set to the Tag ID that has been assigned to the SBD. This is most likely 0 if a VLAN-based or VLAN-bundle service is being used but non-zero if a VLAN-aware bundle service is being used.
* ルートのNLRIのタグIDフィールドは、SBDに割り当てられたタグIDに設定されています。これは、VLANベースまたはVLANバンドルサービスが使用されている場合は0ですが、VLAN認識バンドルサービスが使用されている場合はゼロではありません。
When IR is used to transport IP multicast frames of a given Tenant Domain, each EVPN PE attached to that Tenant Domain MUST originate an SBD-IMET route (see Section 3.2.1).
IRを使用して特定のテナントドメインのIPマルチキャストフレームを輸送する場合、そのテナントドメインに接続された各EVPN PEは、SBD-IMETルートを発生する必要があります（セクション3.2.1を参照）。
The SBD-IMET route MUST carry a PTA, and the MPLS Label field of the PTA MUST specify a downstream-assigned MPLS label that maps uniquely (in the context of the originating EVPN PE) to the SBD.
SBD-IMETルートはPTAを運ぶ必要があり、PTAのMPLSラベルフィールドは、SBDにユニークにマッピングする（発信されたEVPN PEのコンテキストで）マップする下流のMPLSラベルを指定する必要があります。
Following the procedures of [RFC7432], an EVPN PE MUST also originate an IMET route for each BD to which it is attached. Each of these IMET routes carries a PTA specifying a downstream-assigned label that maps uniquely, in the context of the originating EVPN PE, to the BD in question. These IMET routes need not carry the SBD-RT.
[RFC7432]の手順に従って、EVPN PEは、付着する各BDのIMETルートも発生する必要があります。これらのそれぞれのIMETルートには、発信されるEVPN PEのコンテキストで、問題のBDにユニークにマッピングする下流の割り当てラベルを指定するPTAが搭載されています。これらのIMETルートは、SBD-RTを運ぶ必要はありません。
When an ingress EVPN PE needs to use IR to send an IP multicast frame from a particular source BD to an egress EVPN PE, the ingress PE determines whether or not the egress PE has originated an IMET route for that BD. If so, that IMET route contains the MPLS label that the egress PE has assigned to the source BD. The ingress PE uses that label when transmitting the packet to the egress PE. Otherwise, the ingress PE uses the label that the egress PE has assigned to the SBD (in the SBD-IMET route originated by the egress).
侵入EVPN PEがIRを使用して特定のソースBDから出力EVPN PEにIPマルチキャストフレームを送信する必要がある場合、侵入PEは、出口PEがそのBDのIMETルートを発信したかどうかを決定します。その場合、そのIMETルートには、出力PEがソースBDに割り当てたMPLSラベルが含まれています。Ingress PEは、パケットを出力PEに送信するときにそのラベルを使用します。それ以外の場合、Ingress PEは、出口PEがSBDに割り当てたラベルを使用します（出口によって発生するSBD-IMETルートで）。
Note that the set of IMET routes originated by a given egress PE, and installed by a given ingress PE, may change over time. If the egress PE withdraws its IMET route for the source BD, the ingress PE MUST stop using the label carried in that IMET route and instead MUST use the label carried in the SBD-IMET route from that egress PE. Implementors must also take into account that an IMET route from a particular PE for a particular BD may arrive after that PE's SBD-IMET route.
特定の出力PEから発信され、特定の侵入PEによって設置されたIMETルートのセットは、時間とともに変化する可能性があることに注意してください。出口PEがソースBDのIMETルートを撤回した場合、イングレスPEはそのIMETルートで運ばれたラベルの使用を停止する必要があり、代わりにその出力PEからSBD-IMETルートで運ばれるラベルを使用する必要があります。また、実装者は、特定のBDの特定のPEからのIMETルートが、そのPEのSBD-IMETルートの後に到着する可能性があることを考慮する必要があります。
When AR is used to transport IP multicast frames of a given Tenant Domain, each EVPN PE (including the AR-REPLICATOR) attached to the Tenant Domain MUST originate an SBD-IMET route (see Section 3.2.1).
ARを使用して特定のテナントドメインのIPマルチキャストフレームを輸送する場合、各EVPN PE（AR-Replicatorを含む）がテナントドメインに接続されている必要があります。
An AR-REPLICATOR attached to a given Tenant Domain is considered to be an EVPN PE of that Tenant Domain. It is attached to all the BDs in the Tenant Domain, but it does not necessarily have L3 routing instances.
特定のテナントドメインに接続されたARレプリケーターは、そのテナントドメインのEVPN PEと見なされます。テナントドメイン内のすべてのBDSに接続されていますが、必ずしもL3ルーティングインスタンスがあるわけではありません。
As with IR, the SBD-IMET route carries a PTA where the MPLS Label field specifies the downstream-assigned MPLS label that identifies the SBD. However, the AR-REPLICATOR and AR-LEAF EVPN PEs will set the PTA's flags differently, as per [RFC9574].
IRと同様に、SBD-IMETルートには、MPLSラベルフィールドがSBDを識別するダウンストリーム割り当てのMPLSラベルを指定するPTAを搭載しています。ただし、AR-ReplicatorとAR-LEAF EVPN PESは、[RFC9574]に従って、PTAのフラグを異なる方法で設定します。
In addition, each EVPN PE originates an IMET route for each BD to which it is attached. As in the case of IR, these routes carry the downstream-assigned MPLS labels that identify the BDs and do not carry the SBD-RT.
さらに、各EVPN PEは、それが取り付けられている各BDのIMETルートを発信します。IRの場合と同様に、これらのルートは、BDSを識別し、SBD-RTを携帯していない下流で割り当てられたMPLSラベルを搭載しています。
When an ingress EVPN PE, acting as AR-LEAF, needs to send an IP multicast frame from a particular source BD to an egress EVPN PE, the ingress PE determines whether or not there is any AR-REPLICATOR that originated an IMET route for that BD. After the AR-REPLICATOR selection (if there are more than one), the AR-LEAF uses the label contained in the IMET route of the AR-REPLICATOR when transmitting packets to it. The AR-REPLICATOR receives the packet and, based on the procedures specified in [RFC9574] and in Section 3.2.2 of this document, transmits the packets to the egress EVPN PEs using the labels contained in the received IMET routes for either the source BD or the SBD.
AR-LEAFとして機能するIngress EVPN PEが特定のソースBDからEVPN PEにIPマルチキャストフレームを送信する必要がある場合、Ingress PEは、そのためのIMETルートを発信したAR-Replicatorがあるかどうかを判断します。bd。AR-Replicatorの選択（複数の場合）の後、ARリーフは、パケットを送信するときにAR-ReplicatorのIMETルートに含まれるラベルを使用します。AR-Replicatorは、[RFC9574]で指定された手順に基づいて、このドキュメントのセクション3.2.2でパケットを受信します。またはSBD。
If an ingress AR-LEAF for a given BD has not received any IMET route for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the procedures in Section 3.2.2.
特定のBDの侵入ARリーフがAR-ReplicatorからそのBDのIMETルートを受け取っていない場合、侵入ARリーフはセクション3.2.2の手順に従います。
Each PE needs to know a BD's corresponding SBD. Configuring that information in each BD is one way, but it requires repetitive configuration and consistency checking (to make sure that all the BDs of the same tenant are configured with the same SBD). A better way is to configure the SBD info in the L3 routing instance so that all related BDs will derive the SBD information.
各PEは、BDに対応するSBDを知る必要があります。各BDでその情報を構成することは1つの方法ですが、繰り返しの構成と一貫性チェックが必要です（同じテナントのすべてのBDが同じSBDで構成されていることを確認するため）。より良い方法は、L3ルーティングインスタンスでSBD情報を構成して、関連するすべてのBDSがSBD情報を導出するようにすることです。
An AR-REPLICATOR also needs to know the same information, though it does not necessarily have an L3 routing instance. However, from the EVI-RT EC in a BD's IMET route, an AR-REPLICATOR can derive the corresponding SBD of that BD without any configuration.
AR-Replicatorも同じ情報を知る必要がありますが、必ずしもL3ルーティングインスタンスがあるわけではありません。ただし、BDのIMETルートのEVI-RT ECから、AR-Replicatorは、構成なしでそのBDの対応するSBDを導き出すことができます。
When BIER is used to transport multicast packets of a given Tenant Domain, and a given EVPN PE attached to that Tenant Domain is a possible ingress EVPN PE for traffic originating outside that Tenant Domain, the given EVPN PE MUST originate an SBD-IMET route (see Section 3.2.1).
特定のテナントドメインのマルチキャストパケットを輸送するためにBIERを使用し、そのテナントドメインに接続されている特定のEVPN PEが、そのテナントドメインの外側から発信するトラフィックの侵入EVPN PEである場合、特定のEVPN PEはSBD-IMETルートを発信する必要があります（セクション3.2.1を参照してください）。
In addition, IMET routes that are originated for other BDs in the Tenant Domain MUST carry the SBD-RT.
さらに、テナントドメイン内の他のBDSに対して発信されるIMETルートは、SBD-RTを運ぶ必要があります。
Each IMET route (including but not limited to the SBD-IMET route) MUST carry a PTA. The MPLS Label field of the PTA MUST specify an upstream-assigned MPLS label that maps uniquely (in the context of the originating EVPN PE) to the BD for which the route is originated.
各IMETルート（SBD-IMETルートを含むがこれらに限定されない）は、PTAを運ぶ必要があります。PTAのMPLSラベルフィールドは、ルートが発信されるBDにユニークにマッピングされた上流のMPLSラベルを指定する必要があります。
Suppose an ingress EVPN PE, say PE1, needs to use BIER to tunnel an IP multicast frame to a set of egress EVPN PEs. And suppose the frame's source BD is BD1. The frame is encapsulated as follows:
たとえばPE1たとえば、侵入EVPN PEがBierを使用して、IPマルチキャストフレームを一連の出力EVPN PESにトンネルする必要があるとします。フレームのソースBDがBD1であると仮定します。フレームは次のようにカプセル化されています。
* A four-octet MPLS label stack entry [RFC3032] is prepended to the frame. The Label field is set to the upstream-assigned label that PE1 has assigned to BD1.
* 4オクテットのMPLSラベルスタックエントリ[RFC3032]がフレームに加えられます。ラベルフィールドは、PE1がBD1に割り当てたアップストリーム割り当てラベルに設定されています。
* The resulting MPLS packet is then encapsulated in a BIER encapsulation [RFC8296] [RFC9624]. The BIER BitString is set to identify the egress EVPN PEs. The BIER Proto field is set to the value for "MPLS packet with an upstream-assigned label at top of the stack".
* 結果のMPLSパケットは、ビアカプセル化[RFC8296] [RFC9624]にカプセル化されます。Bier BitStringは、出力EVPN PESを識別するように設定されています。Bier Protoフィールドは、「スタックの上部に上流のラベルが付いたMPLSパケット」の値に設定されています。
Note: It is possible that the packet being tunneled from PE1 originated outside the Tenant Domain. In this case, the actual source BD, BD1, is considered to be the SBD, and the upstream-assigned label it carries will be the label that PE1 assigned to the SBD and advertised in its SBD-IMET route.
注：PE1からトンネリングされているパケットがテナントドメインの外側に起源がある可能性があります。この場合、実際のソースBDであるBD1はSBDと見なされ、それが運ぶアップストリーム割り当てラベルは、SBDに割り当てられ、SBD-IMETルートで宣伝されているPE1がラベルになります。
Suppose an egress PE, say PE2, receives such a BIER packet. The BFIR-id field of the BIER header allows PE2 to determine that the ingress PE is PE1. There are then two cases to consider:
たとえばPE2がそのようなビアパケットを受け取ると仮定します。BierヘッダーのBFIR-IDフィールドにより、PE2は侵入PEがPE1であると判断できます。その後、考慮すべき2つのケースがあります。
1. PE2 has received and installed an IMET route for BD1 from PE1.
1. PE2は、PE1からBD1用のIMETルートを受信してインストールしました。
In this case, the BIER packet will be carrying the upstream-assigned label that is specified in the PTA of that IMET route. This enables PE2 to determine the apparent source BD (as defined in Section 2.4).
この場合、Bierパケットは、そのIMETルートのPTAで指定されている上流で割り当てられたラベルを運びます。これにより、PE2は見かけのソースBDを決定できます（セクション2.4で定義されています）。
2. PE2 has not received and installed an IMET route for BD1 from PE1.
2. PE2は、PE1からBD1用のIMETルートを受信およびインストールしていません。
In this case, PE2 will not recognize the upstream-assigned label carried in the BIER packet. PE2 MUST discard the packet.
この場合、PE2はBierパケットに運ばれるアップストリーム割り当てのラベルを認識しません。PE2はパケットを破棄する必要があります。
Further details on the use of BIER to support EVPN can be found in [RFC9624].
EVPNをサポートするためのBierの使用に関する詳細については、[RFC9624]をご覧ください。
The procedures in this section apply only when:
このセクションの手順は、次の場合にのみ適用されます。
a) it is desired to use the BUM tunnels to carry IP multicast traffic across the backbone and
a) バックボーン全体にIPマルチキャストトラフィックを運ぶために、Bumトンネルを使用することが望まれます
b) the BUM tunnels are P2MP tunnels (i.e., neither IR, AR, nor BIER are being used to transport the BUM traffic).
b) BumトンネルはP2MPトンネルです（つまり、IR、AR、およびビアのどちらも、バムトラフィックの輸送に使用されていません）。
In this case, an IP multicast frame (whether inter-subnet or intra-subnet) will be carried across the backbone in the BUM tunnel belonging to its source BD. Each EVPN PE attached to a given Tenant Domain needs to join the BUM tunnels for every BD in the Tenant Domain, even those BDs to which the EVPN PE is not locally attached. This ensures that an IP multicast packet from any source BD can reach all PEs attached to the Tenant Domain.
この場合、IPマルチキャストフレーム（インターサブネットまたはサブネット内）が、そのソースBDに属するバムトンネルのバックボーンを横切って運ばれます。特定のテナントドメインに接続された各EVPN PEは、EVPN PEが局所的に接続されていないBDでも、テナントドメインのすべてのBDのバムトンネルに参加する必要があります。これにより、任意のソースBDからのIPマルチキャストパケットがテナントドメインに接続されたすべてのPEに到達できるようになります。
Note that this will cause all the BUM traffic from a given BD in a Tenant Domain to be sent to all PEs that attach to that Tenant Domain, even the PEs that don't attach to the given BD. To avoid this, it is RECOMMENDED that the BUM tunnels not be used as IP multicast inclusive tunnels and that the procedures of Section 3.2.5.2 be used instead.
これにより、テナントドメインの特定のBDからのすべてのバムトラフィックが、そのテナントドメインに付着するすべてのPEに送信されることに注意してください。これを避けるために、BumトンネルをIPマルチキャスト包括的トンネルとして使用しないこと、およびセクション3.2.5.2の手順を代わりに使用することをお勧めします。
If a PE is a possible ingress EVPN PE for traffic originating outside the Tenant Domain, the PE MUST originate an SBD-IMET route (see Section 3.2.1). This route MUST carry a PTA specifying the P2MP tunnel used for transmitting IP multicast packets that originate outside the Tenant Domain. All EVPN PEs of the Tenant Domain MUST join the tunnel specified in the PTA of an SBD-IMET route:
PEがテナントドメインの外側にあるトラフィックの可能性のあるEVPN PEである場合、PEはSBD-IMETルートを発信する必要があります（セクション3.2.1を参照）。このルートは、テナントドメインの外側から発生するIPマルチキャストパケットの送信に使用されるP2MPトンネルを指定するPTAを運ぶ必要があります。テナントドメインのすべてのEVPN PESは、SBD-IMETルートのPTAで指定されたトンネルに結合する必要があります。
* If the tunnel is an RSVP-TE P2MP tunnel, the originator of the route MUST use RSVP-TE P2MP procedures to add each PE of the Tenant Domain to the tunnel, even PEs that have not originated an SBD-IMET route.
* トンネルがRSVP-TE P2MPトンネルである場合、ルートの創始者はRSVP-TE P2MP手順を使用して、テナントドメインの各PEをトンネルに追加する必要があります。
* If the tunnel is an mLDP or PIM tunnel, each PE importing the SBD-IMET route MUST add itself to the tunnel, using mLDP or PIM procedures, respectively.
* トンネルがMLDPまたはPIMトンネルである場合、SBD-IMETルートをインポートする各PEは、それぞれMLDPまたはPIM手順を使用してトンネルに追加する必要があります。
Whether or not a PE originates an SBD-IMET route, it will of course originate an IMET route for each BD to which it is attached. Each of these IMET routes MUST carry the SBD-RT, as well as the RT for the BD to which it belongs.
PEがSBD-IMETルートを起源とするかどうかにかかわらず、もちろん、それが取り付けられている各BDのIMETルートが発生します。これらのIMETルートのそれぞれは、SBD-RTと、それが属するBDのRTを運ぶ必要があります。
If a received IMET route is not the SBD-IMET route, it will also be carrying the RT for its source BD. The route's NLRI will carry the Tag ID for the source BD. From the RT and the Tag ID, any PE receiving the route can determine the route's source BD.
受信したIMETルートがSBD-IMETルートではない場合、ソースBDのRTも運びます。ルートのNLRIは、ソースBDのタグIDを運びます。RTとタグIDから、ルートを受信するPEは、ルートのソースBDを決定できます。
If the MPLS Label field of the PTA contains zero, the specified P2MP tunnel is used only to carry frames of a single source BD.
PTAのMPLSラベルフィールドにゼロが含まれている場合、指定されたP2MPトンネルは、単一のソースBDのフレームを運ぶためにのみ使用されます。
If the MPLS Label field of the PTA does not contain zero, it MUST contain an upstream-assigned MPLS label that maps uniquely (in the context of the originating EVPN PE) to the source BD (or in the case of an SBD-IMET route, to the SBD). The tunnel may then be used to carry frames of multiple source BDs. The apparent source BD of a particular packet is inferred from the label carried by the packet.
PTAのMPLSラベルフィールドにゼロが含まれていない場合、ソースBDに一意にマッピングする上流のMPLSラベルを含む必要があります（またはSBD-IMETルートの場合、SBDへ）。トンネルは、複数のソースBDのフレームを運ぶために使用できます。特定のパケットの見かけのソースBDは、パケットによって運ばれるラベルから推測されます。
IP multicast traffic originating outside the Tenant Domain is transmitted with the label corresponding to the SBD, as specified in the ingress EVPN PE's SBD-IMET route.
テナントドメインの外側にあるIPマルチキャストトラフィックは、侵入EVPN PEのSBD-IMETルートで指定されているように、SBDに対応するラベルで送信されます。
The procedures of this section apply when (and only when) it is desired to transmit IP multicast traffic on an inclusive tunnel but not on the same tunnel used to transmit BUM traffic.
このセクションの手順は、IPマルチキャストトラフィックを包括的なトンネルに送信することが望まれますが、BUMトラフィックを送信するために使用されるのと同じトンネルでは適用されません。
However, these procedures do NOT apply when the tunnel type is IR or BIER, EXCEPT in the case where it is necessary to interwork between non-OISM PEs and OISM PEs, as specified in Section 5.
ただし、セクション5で指定されているように、トンネルタイプがIRまたはビアの場合、非オームPEとOISM PEの間でインターワークする必要がある場合を除き、これらの手順は適用されません。
Each EVPN PE attached to the given Tenant Domain MUST originate an SBD-SPMSI A-D route. The NLRI of that route MUST contain (C-*,C-*) (see [RFC6625]). Additional rules for constructing that route are given in Section 3.2.1.
特定のテナントドメインに接続された各EVPN PEは、SBD-SPMSI A-Dルートを発信する必要があります。そのルートのNLRIには（c - *、c-*）を含める必要があります（[rfc6625]を参照）。そのルートを構築するための追加のルールは、セクション3.2.1に記載されています。
In addition, an EVPN PE MUST originate an S-PMSI A-D route containing (C-*,C-*) in its NLRI for each of the other BDs, in the given Tenant Domain, to which it is attached. All such routes MUST carry the SBD-RT. This ensures that those routes are imported by all EVPN PEs attached to the Tenant Domain.
さらに、EVPN PEは、他の各BDSのNLRIに（C - *、C-*）を含むS-PMSI A-Dルートを、接続されている特定のテナントドメインで発生する必要があります。そのようなルートはすべて、SBD-RTを運ぶ必要があります。これにより、これらのルートは、テナントドメインに接続されたすべてのEVPN PEによってインポートされます。
A PE receiving these routes follows the procedures of Section 2.2 to determine which BD the route is for.
これらのルートを受け取るPEは、セクション2.2の手順に従って、ルートのどのBDが向けられているかを決定します。
If the MPLS Label field of the PTA contains zero, the specified tunnel is used only to carry frames of a single source BD.
PTAのMPLSラベルフィールドにゼロが含まれている場合、指定されたトンネルは単一のソースBDのフレームを運ぶためにのみ使用されます。
If the MPLS Label field of the PTA does not contain zero, it MUST specify an upstream-assigned MPLS label that maps uniquely (in the context of the originating EVPN PE) to the source BD. The tunnel may be used to carry frames of multiple source BDs, and the apparent source BD for a particular packet is inferred from the label carried by the packet.
PTAのMPLSラベルフィールドにゼロが含まれていない場合、ソースBDに一意にマッピングするアップストリーム割り当てのMPLSラベルを指定する必要があります。トンネルは複数のソースBDのフレームを運ぶために使用でき、特定のパケットの見かけのソースBDは、パケットによって運ばれるラベルから推測されます。
The EVPN PE advertising these S-PMSI A-D routes is specifying the default tunnel that it will use (as ingress PE) for transmitting IP multicast packets. The upstream-assigned label allows an egress PE to determine the apparent source BD of a given packet.
これらのS-PMSI A-Dルートを宣伝するEVPN PEは、IPマルチキャストパケットを送信するために（Ingress PEとして）使用するデフォルトのトンネルを指定しています。アップストリーム割り当てのラベルにより、出口PEが特定のパケットの見かけのソースBDを決定できます。
An ingress EVPN PE for a given multicast flow or set of flows can always assign the flow to a particular P2MP tunnel by originating an S-PMSI A-D route whose NLRI identifies the flow or set of flows. The NLRI of the route could be (C-*,C-G) or (C-S,C-G). The S-PMSI A-D route MUST carry the SBD-RT so that it is imported by all EVPN PEs attached to the Tenant Domain.
特定のマルチキャストフローまたは一連のフローの侵入EVPN PEは、NLRIがフローまたはフローのセットを識別するS-PMSI A-Dルートを発信することにより、常に特定のP2MPトンネルにフローを割り当てることができます。ルートのNLRIは（c-*、c-g）または（c-s、c-g）である可能性があります。S-PMSI A-Dルートは、テナントドメインに接続されたすべてのEVPN PEによってインポートされるようにSBD-RTを運ぶ必要があります。
An S-PMSI A-D route is for a particular source BD. It MUST carry the RT associated with that BD, and it MUST have the Tag ID for that BD in its NLRI.
S-PMSI A-Dルートは、特定のソースBD用です。そのBDに関連付けられたRTを運ぶ必要があり、NLRIにそのBDのタグIDが必要です。
When an EVPN PE imports an S-PMSI A-D route, it applies the rules of Section 2.2 to associate the route with a particular BD.
EVPN PEがS-PMSI A-Dルートをインポートすると、セクション2.2のルールを適用して、ルートを特定のBDに関連付けます。
Each such route MUST contain a PTA, as specified in Section 3.2.5.2.
このような各ルートには、セクション3.2.5.2で指定されているように、PTAが含まれている必要があります。
An egress EVPN PE interested in the specified flow or flows MUST join the specified tunnel. Procedures for joining the specified tunnel are specific to the tunnel type. (Note that if the tunnel type is RSVP-TE P2MP LSP, the Leaf Information Required (LIR) flag of the PTA SHOULD NOT be set. An ingress OISM PE knows which OISM EVPN PEs are interested in any given flow and hence can add them to the RSVP-TE P2MP tunnel that carries such flows.)
指定されたフローまたはフローに関心のある出力EVPN PEは、指定されたトンネルに結合する必要があります。指定されたトンネルを結合するための手順は、トンネルタイプに固有です。（トンネルタイプがRSVP-TE P2MP LSPの場合、PTAの葉の情報（LIR）フラグを設定しないでください。どのoism evpn pesが特定のフローに関心があるかを知っているため、それらを追加できます。そのようなフローを運ぶRSVP-TE P2MPトンネルへ。）
If the PTA does not specify a non-zero MPLS label, the apparent source BD of any packets that arrive on that tunnel is considered to be the BD associated with the route that carries the PTA. If the PTA does specify a non-zero MPLS label, the apparent source BD of any packets that arrive on that tunnel carrying the specified label is considered to be the BD associated with the route that carries the PTA.
PTAが非ゼロMPLSラベルを指定していない場合、そのトンネルに到着したパケットの見かけのソースBDは、PTAを運ぶルートに関連付けられたBDと見なされます。PTAが非ゼロMPLSラベルを指定している場合、指定されたラベルを運ぶトンネルに到着するパケットの見かけのソースBDは、PTAを運ぶルートに関連付けられたBDと見なされます。
It should be noted that, when either IR or BIER is used, there is no need for an ingress PE to use S-PMSI A-D routes to assign specific flows to selective tunnels. The procedures of Section 3.3, along with the procedures of Sections 3.2.2, 3.2.3, and 3.2.4, provide the functionality of selective tunnels without the need to use S-PMSI A-D routes.
IRまたはBIERのいずれかを使用している場合、S-PMSI A-Dルートを使用して特定のフローを選択的トンネルに割り当てる必要はないことに注意してください。セクション3.3の手順は、セクション3.2.2、3.2.3、および3.2.4の手順とともに、S-PMSI A-Dルートを使用することなく、選択的トンネルの機能を提供します。
[RFC9251] allows an egress EVPN PE to express its interest in a particular multicast flow or set of flows by originating a SMET route. The NLRI of the SMET route identifies the flow or set of flows as (C-*,C-*), (C-*,C-G), or (C-S,C-G).
[RFC9251]により、EVPN PEは、SMETルートを発信することにより、特定のマルチキャストフローまたはフローのセットに対する関心を表明できます。SMETルートのNLRIは、フローまたはフローのセットを（c - *、c-*）、（c-*、c-g）、または（c-s、c-g）として識別します。
Each SMET route belongs to a particular BD. The Tag ID for the BD appears in the NLRI of the route, and the route carries the RT associated with that BD. From this <RT, tag> pair, other EVPN PEs can identify the BD to which a received SMET route belongs. (Remember though that the route may be carrying multiple RTs.)
各SMETルートは特定のBDに属します。BDのタグIDはルートのNLRIに表示され、ルートにはそのBDに関連付けられたRTが搭載されています。この<rt、tag>ペアから、他のevpn pesは、受信したSmetルートが属するBDを識別できます。（ルートは複数のRTを搭載している可能性があることを忘れないでください。）
There are three cases to consider:
考慮すべき3つのケースがあります。
Case 1: It is known that no BD of a Tenant Domain contains a multicast router.
ケース1：テナントドメインのBDにはマルチキャストルーターが含まれていないことが知られています。
In this case, an egress PE advertises its interest in a flow or set of flows by originating a SMET route that belongs to the SBD. We refer to this as an SBD-SMET route. The SBD-SMET route carries the SBD-RT and has the Tag ID for the SBD in its NLRI. SMET routes for the individual BDs are not needed, because there is no need for a PE that receives a SMET route to send a corresponding IGMP/MLD Join message on any of its ACs.
この場合、出口PEは、SBDに属するSMETルートを発信することにより、流れまたは一連のフローに対する関心を宣伝します。これをSBD-Smetルートと呼びます。SBD-SmetルートにはSBD-RTが搭載されており、NLRIのSBDのタグIDがあります。個々のBDSのSMETルートは必要ありません。これは、ACSのいずれかで対応するIGMP/MLD参加メッセージを送信するためにSMETルートを受信するPEが必要ないためです。
Case 2: It is known that more than one BD of a Tenant Domain may contain a multicast router.
ケース2：テナントドメインの複数のBDにマルチキャストルーターが含まれている可能性があることが知られています。
This is much like Case 1. An egress PE advertises its interest in a flow or set of flows by originating an SBD-SMET route. The SBD-SMET route carries the SBD-RT and has the Tag ID for the SBD in its NLRI.
これはケース1によく似ています。出口PEは、SBDスメットルートを発信することにより、フローまたはフローセットへの関心を宣伝します。SBD-SmetルートにはSBD-RTが搭載されており、NLRIのSBDのタグIDがあります。
In this case, it is important to be sure that SMET routes for the individual BDs are not originated. For example, suppose that PE1 had local receivers for a given flow on both BD1 and BD2 and that it originated SMET routes for both those BDs. Then, PEs receiving those SMET routes might send IGMP/MLD Joins on both those BDs. This could cause externally sourced multicast traffic to enter the Tenant Domain at both BDs, which could result in duplication of data.
この場合、個々のBDSのSMETルートが発生していないことを確認することが重要です。たとえば、PE1がBD1とBD2の両方に与えられたフローのローカルレシーバーを持っていて、それらの両方のBDのSMETルートが発生したと仮定します。次に、これらのSMETルートを受け取るPESは、両方のBDでIGMP/MLD結合を送信する可能性があります。これにより、外部から調達されたマルチキャストトラフィックが両方のBDSでテナントドメインに入る可能性があり、その結果、データが複製される可能性があります。
Note that if it is possible that more than one BD contains a tenant multicast router, then in order to receive multicast data originating from outside EVPN, the PEs MUST follow the procedures of Section 6.
複数のBDにテナントマルチキャストルーターが含まれている可能性がある場合は、外部EVPNから発信されるマルチキャストデータを受信するために、PESはセクション6の手順に従う必要があることに注意してください。
Case 3: It is known that only a single BD of a Tenant Domain contains a multicast router.
ケース3：テナントドメインの単一のBDのみにマルチキャストルーターが含まれていることが知られています。
Suppose that an egress PE is attached to a BD on which there might be a tenant multicast router. (The tenant router is not necessarily on a segment that is attached to that PE.) And suppose that the PE has one or more ACs attached to that BD, which are interested in a given multicast flow. In this case, in addition to the SMET route for the SBD, the egress PE MAY originate a SMET route for that BD. This will enable the ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in [RFC9251]. As long as that is the only BD on which there is a tenant multicast router, there is no possibility of duplication of data.
出口PEがテナントマルチキャストルーターがある可能性のあるBDに取り付けられていると仮定します。（テナントルーターは、必ずしもそのPEに接続されているセグメントにあるわけではありません。）そして、PEには、特定のマルチキャストフローに関心のあるBDに1つ以上のACSが付属していると仮定します。この場合、SBDのSMETルートに加えて、出口PEはそのBDのSMETルートを発生する可能性があります。これにより、[RFC9251]で指定されているように、Ingress PEがBDのACSにIGMP/MLDメッセージを送信できます。それがテナントマルチキャストルーターがある唯一のBDである限り、データの複製の可能性はありません。
This document does not specify procedures for dynamically determining which of the three cases applies to a given deployment; the PEs of a given Tenant Domain MUST be provisioned to know which case applies.
このドキュメントでは、3つのケースのどれが特定の展開に適用されるかを動的に決定する手順を指定していません。特定のテナントドメインのPESをプロビジョニングして、どのケースが適用されるかを知る必要があります。
As detailed in [RFC9251], a SMET route carries flags indicating whether IGMP (v1, v2, or v3) or MLD (v1 or v2) messages should be triggered on the ACs of the BD to which the SMET route belongs. For IGMP v3 and MLD v2, the Include/Exclude (IE) flag also indicates whether the source information in the SMET route is of an Include Group type or Exclude Group type. If an SBD PE needs to generate IGMP/MLD reports (as it is the case in Section 6.2) or the route is for an (S, G) state, the value of the flags MUST be set according to the rules in [RFC9251]. Otherwise, the flags SHOULD be set to 0.
[RFC9251]で詳述されているように、SMETルートには、IGMP（V1、V2、またはV3）またはMLD（V1またはV2）メッセージがSMETルートが属するBDのACSでトリガーする必要があるかどうかを示すフラグがあります。IGMP V3およびMLD V2の場合、SMETルートのソース情報がインクルードグループタイプか除外グループタイプであるかを含む/除外（IE）フラグも示します。SBD PEがIGMP/MLDレポートを生成する必要がある場合（セクション6.2の場合と同様）、またはルートは（s、g）状態の場合、[RFC9251]のルールに従ってフラグの値を設定する必要があります。。それ以外の場合、フラグは0に設定する必要があります。
Note that a PE only needs to originate the set of SBD-SMET routes that are needed in order to receive multicast traffic that the PE is interested in. Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G) traffic and ACs attached to BD2 that are interested in (C-S,C-G) traffic. A single SBD-SMET route specifying (C-*,C-G) will attract all the necessary flows.
PEは、PEが関心を持っているマルチキャストトラフィックを受信するために必要なSBDスメットルートのセットのみを発信する必要があることに注意してください。PE1が（C-*、C-G）トラフィックに関心のあるBD1に接続されていると仮定します。（C-S、C-G）トラフィックに関心のあるBD2に接続されているACS。指定（c - *、c-g）を指定する単一のSBDスメットルートは、必要なすべてのフローを引き付けます。
As another example, suppose the ACs attached to BD1 are interested in (C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are interested in (C-S,C-G). A single SBD-SMET route specifying (C-*,C-G) will pull in all the necessary flows.
別の例として、BD1に接続されたACSが（c-*、c-g）に関心があるが（c-s、c-g）、BD2に接続されたACSが（c-s、c-g）に関心を持っていないと仮定します。指定（C - *、C-G）を指定する単一のSBD-SMETルートが必要なすべてのフローを引き込みます。
In other words, to determine the set of SBD-SMET routes that have to be sent for a given C-G, the PE has to merge the IGMP/MLD state for all the BDs (of the given Tenant Domain) to which it is attached.
言い換えれば、特定のC-gに対して送信する必要があるSBDスメットルートのセットを決定するには、PEは、接続されているすべてのBDS（与えられたテナントドメインの）のIGMP/MLD状態をマージする必要があります。
Per [RFC9251], importing a SMET route for a particular BD will cause the IGMP/MLD state to be instantiated for the IRB interface to that BD. This also applies when the BD is the SBD.
[RFC9251]ごとに、特定のBDのSMETルートをインポートすると、IGMP/MLD状態がIRBインターフェースのIRBインターフェースのインスタンス化されます。これは、BDがSBDである場合にも適用されます。
However, traffic that originates in one of the actual BDs of a particular Tenant Domain MUST NOT be sent down the IRB interface that connects the L3 routing instance of that Tenant Domain to the SBD. That would cause duplicate delivery of traffic, since such traffic will have already been distributed throughout the Tenant Domain. Therefore, when setting up the IGMP/MLD state based on SBD-SMET routes, care must be taken to ensure that the IRB interface to the SBD is not added to the Outgoing Interface (OIF) list if the traffic originates within the Tenant Domain.
ただし、特定のテナントドメインの実際のBDの1つに由来するトラフィックを、そのテナントドメインのL3ルーティングインスタンスをSBDに接続するIRBインターフェイスを下に送信する必要はありません。このようなトラフィックはすでにテナントドメイン全体に分配されているため、トラフィックの重複の配送が発生します。したがって、SBDスメットルートに基づいてIGMP/MLD状態をセットアップするときは、テナントドメイン内でトラフィックが発生する場合、SBDへのIRBインターフェイスが発信インターフェイス（OIF）リストに追加されないように注意する必要があります。
There are some multicast scenarios that make use of anycast sources. For example, two different sources may share the same anycast IP address, say S1, and each may transmit an (S1,G) multicast flow. In such a scenario, the two (S1,G) flows are typically identical. Ordinary PIM procedures will cause only one of the flows to be delivered to each receiver that has expressed interest in either (*,G) or (S1,G). However, the OISM procedures described in this document will result in both of the (S1,G) flows being distributed in the Tenant Domain, and duplicate delivery will result. Therefore, if there are receivers for (*,G) in a given Tenant Domain, there MUST NOT be anycast sources for G within that Tenant Domain. (This restriction could be lifted by defining additional procedures; however, that is outside the scope of this document.)
Anycastソースを利用するマルチキャストシナリオがいくつかあります。たとえば、2つの異なるソースは、同じAnycast IPアドレス、たとえばS1を共有する場合があり、それぞれが（S1、G）マルチキャストフローを送信する場合があります。このようなシナリオでは、2つの（S1、g）フローは通常同一です。通常のPIM手順により、フローの1つのみが各レシーバーに配信され、（*、g）または（s1、g）のいずれかに関心を示します。ただし、このドキュメントで説明されているOISM手順により、（S1、g）フローの両方がテナントドメインに分散され、重複する配信が生じます。したがって、特定のテナントドメインに（*、g）の受信機がある場合、そのテナントドメイン内にGのautast Sourceが存在してはなりません。（この制限は、追加の手順を定義することで解除できます。ただし、このドキュメントの範囲外です。）
An EVPN PE maintains Layer 2 multicast state for each BD to which it is attached. Note that this is used for forwarding IP multicast frames based on the inner IP header. The state is learned through IGMP/MLD snooping [RFC4541] and procedures in this document.
EVPN PEは、それが取り付けられている各BDのレイヤー2マルチキャスト状態を維持します。これは、内側のIPヘッダーに基づいてIPマルチキャストフレームを転送するために使用されることに注意してください。状態は、IGMP/MLDスヌーピング[RFC4541]とこのドキュメントの手順を通じて学習されます。
Let PE1 be an EVPN PE and BD1 be a BD to which it is attached. At PE1, BD1's Layer 2 multicast state for a given (C-S,C-G) or (C-*,C-G) governs the disposition of an IP multicast packet that is received by BD1's Layer 2 multicast function on an EVPN PE.
PE1をEVPN PEおよびBD1とし、それが接続されているBDとします。PE1では、特定の（C-S、C-G）または（C-*、C-G）のBD1のレイヤー2マルチキャスト状態は、EVPN PEでBD1のレイヤー2マルチキャスト関数によって受信されるIPマルチキャストパケットの処分を規定しています。
An IP multicast (S,G) packet is considered to have been received by BD1's Layer 2 multicast function in PE1 in the following cases:
IPマルチキャスト（S、G）パケットは、次の場合にBD1のレイヤー2マルチキャスト関数によって受信されたと見なされます。
* The packet is the payload of an Ethernet frame received by PE1 from an AC that attaches to BD1.
* パケットは、BD1に付着するACからPE1が受信したイーサネットフレームのペイロードです。
* The packet is the payload of an Ethernet frame whose apparent source BD is BD1, which is received by the PE1 over a tunnel from another EVPN PE.
* パケットは、見かけのソースBDがBD1であるイーサネットフレームのペイロードであり、PE1が別のEVPN PEからトンネル上で受信します。
* The packet is received from BD1's IRB interface (i.e., has been transmitted by PE1's L3 routing instance down BD1's IRB interface).
* このパケットは、BD1のIRBインターフェイスから受信されます（つまり、BD1のIRBインターフェイスにあるPE1のL3ルーティングインスタンスによって送信されました）。
According to the procedures of this document, all transmissions of IP multicast packets from one EVPN PE to another are done at Layer 2. That is, the packets are transmitted as Ethernet frames, according to the Layer 2 multicast state.
このドキュメントの手順によると、1つのEVPN PEから別のEVPN PEへのIPマルチキャストパケットのすべての送信は、レイヤー2で行われます。つまり、レイヤー2マルチキャスト状態に従って、パケットはイーサネットフレームとして送信されます。
Each Layer 2 multicast state (S,G) or (*,G) contains a set of outgoing interfaces (an OIF list). The disposition of an (S,G) multicast frame received by BD1's Layer 2 multicast function is determined as follows:
各レイヤー2マルチキャスト状態（s、g）または（*、g）には、一連の発信インターフェイス（OIFリスト）が含まれています。BD1のレイヤー2マルチキャスト関数で受け取った（s、g）マルチキャストフレームの処分は、次のように決定されます。
* The OIF list is taken from BD1's Layer 2 (S,G) state, or if there is no such (S,G) state, then it is taken from BD1's (*,G) state. (If neither state exists, the OIF list is considered to be null.)
* OIFリストは、BD1のレイヤー2（s、g）状態から取得されます。または、そのような（s、g）状態がない場合は、BD1（*、g）状態から取得されます。（どちらの状態も存在しない場合、OIFリストはnullと見なされます。）
* The rules of Section 4.1.2 are applied to the OIF list. This will generally result in the frame being transmitted to some, but not all, elements of the OIF list.
* セクション4.1.2のルールは、OIFリストに適用されます。これにより、通常、フレームがOIFリストのすべてではなく、一部に送信されます。
Note that there is no Reverse Path Forwarding (RPF) check at Layer 2.
レイヤー2に逆パス転送（RPF）チェックがないことに注意してください。
In this document, we have extended the procedures of [RFC9251] so that IMET and SMET routes for a particular BD are distributed not just to PEs that attach to that BD but to PEs that attach to any BD in the Tenant Domain. In this way, each PE attached to a given Tenant Domain learns, from another PE attached to the same Tenant Domain, the set of flows that are of interest to each of those other PEs. (If some PE attached to the Tenant Domain does not support [RFC9251], it will be assumed to be interested in all flows. Whether or not a particular remote PE supports [RFC9251] is determined by the presence of an Extended Community in its IMET route; this is specified in [RFC9251].) If a set of remote PEs are interested in a particular flow, the tunnels used to reach those PEs are added to the OIF list of the multicast states corresponding to that flow.
このドキュメントでは、[RFC9251]の手順を拡張して、特定のBDのIMETとSMETルートが、そのBDに付着するPESだけでなく、テナントドメインの任意のBDに付着するPEに分布するようにしました。このようにして、特定のテナントドメインに接続された各PEは、同じテナントドメインに接続された別のPEから、それらのそれぞれのPEに興味のある一連のフローを学習します。（テナントドメインに接続されたPEが[RFC9251]をサポートしていない場合、すべてのフローに関心があると想定されます。特定のリモートPEサポート[RFC9251]が、そのIMETに拡張されたコミュニティの存在によって決定されるかどうかこれは[RFC9251]で指定されています。）リモートPEのセットが特定のフローに関心がある場合、それらのPEに到達するために使用されるトンネルは、その流れに対応するマルチキャスト状態のOIFリストに追加されます。
An EVPN PE may run IGMP/MLD snooping procedures [RFC4541] on each of its ACs in order to determine the set of flows of interest to each AC. (An AC is said to be interested in a given flow if it connects to a segment that has tenant systems interested in that flow.) If IGMP/MLD procedures are not being run on a given AC, that AC is considered to be interested in all flows. For each BD, the set of ACs interested in a given flow is determined, and the ACs of that set are added to the OIF list of that BD's multicast state for that flow.
EVPN PEは、各ACの関心のあるフローのセットを決定するために、各ACSでIGMP/MLDスヌーピング手順[RFC4541]を実行する場合があります。（ACは、そのフローに関心のあるテナントシステムがあるセグメントに接続している場合、特定のフローに関心があると言われています。）IGMP/MLD手順が特定のACで実行されていない場合、ACは関心があると考えられていますすべての流れ。各BDについて、特定のフローに関心のあるACSのセットが決定され、そのセットのACSは、そのフローのためにそのBDのマルチキャスト状態のOIFリストに追加されます。
The OIF list for each multicast state must also contain the IRB interface for the BD to which the state belongs.
各マルチキャスト状態のOIFリストには、状態が属するBDのIRBインターフェイスも含める必要があります。
Implementors should note that the OIF list of a multicast state will change from time to time as ACs and/or remote PEs either become interested in or lose interest in particular multicast flows.
実装者は、マルチキャスト状態のOIFリストは、ACSおよび/またはリモートPEが特定のマルチキャストフローに興味を持つか、興味を失うようになるため、時々変更されることに注意する必要があります。
When an (S,G) multicast frame is received by the Layer 2 multicast function of a given EVPN PE, say PE1, its disposition depends upon (a) the way it was received, (b) the OIF list of the corresponding multicast state (see Section 4.1.1), (c) the eligibility of an AC to receive a given frame (see Section 4.1.2.1), and (d) its apparent source BD (see Section 3.2 for information about determining the apparent source BD of a frame received over a tunnel from another PE).
（s、g）マルチキャストフレームが特定のevpn peのレイヤー2マルチキャスト関数によって受信される場合、たとえば、その性質は（a）受け取った方法に依存します（b）対応するマルチキャスト状態のOIFリスト（セクション4.1.1を参照）、（c）特定のフレームを受信するACの適格性（セクション4.1.2.1を参照）、および（d）その見かけのソースBD（セクション3.2を参照してください。別のPEからトンネルを介して受け取ったフレーム）。
A given (S,G) multicast frame is eligible to be transmitted by a given PE, say PE1, on a given AC, say AC1, only if one of the following conditions holds:
与えられた（s、g）マルチキャストフレームは、特定のAC、たとえばAC1などの特定のPE、たとえばPE1によって送信される資格があります。
1. Ethernet Segment Identifier (ESI) labels are being used, PE1 is the DF for the segment to which AC1 is connected, and the frame did not originate from that same segment (as determined by the ESI label).
1. イーサネットセグメント識別子（ESI）ラベルが使用されています。PE1はAC1が接続されているセグメントのDFであり、フレームは同じセグメントから発生しませんでした（ESIラベルで決定されます）。
2. The ingress PE for the frame is a remote PE, say PE2, local bias is being used, and PE2 is not connected to the same segment as AC1.
2. フレームの侵入PEはリモートPE、たとえばPE2、ローカルバイアスが使用されており、PE2はAC1と同じセグメントに接続されていません。
Assume a given (S,G) multicast frame has been received by a given PE, say PE1. PE1 determines the apparent source BD of the frame, finds the Layer 2 (S,G) state for that BD (or the (*,G) state if there is no (S,G) state), and uses the OIF list from that state. (Note that if PE1 is not attached to the actual source BD, the apparent source BD will be the SBD.)
特定の（s、g）マルチキャストフレームが特定のPE、たとえばPE1によって受信されたと仮定します。PE1は、フレームの見かけのソースBDを決定し、そのbd（または（*、g）状態がある場合、そのbd（または（*、g）状態）のレイヤー2（s、g）状態を見つけ、oifリストを使用します。その状態。（PE1が実際のソースBDに接続されていない場合、見かけのソースBDがSBDになることに注意してください。）
If PE1 has determined the frame's apparent source BD to be BD1 (which may or may not be the SBD), then the following cases should be considered:
PE1がフレームの見かけのソースBDをBD1（これはSBDである場合とそうでない場合がある場合）と判断した場合、次のケースを考慮する必要があります。
1. The frame was received by PE1 from a local AC, say AC1, that attaches to BD1.
1. フレームは、BD1に付着するローカルAC、たとえばAC1などのPE1によって受信されました。
a. The frame MUST be sent on all local ACs of BD1 that appear in the OIF list, except for AC1 itself.
a. フレームは、AC1自体を除き、OIFリストに表示されるBD1のすべてのローカルACSで送信する必要があります。
b. The frame MUST also be delivered to any other EVPN PEs that have interest in it. This is achieved as follows:
b. フレームは、関心のある他のEVPN PEにも配信する必要があります。これは次のように達成されます。
i. If (a) AR is being used, (b) PE1 is an AR-LEAF, and (c) the OIF list is non-null, PE1 MUST send the frame to the AR-REPLICATOR.
i. （a）ARが使用されている場合、（b）PE1はARリーフであり、（c）OIFリストは非ヌルである場合、PE1はAR-Replicatorにフレームを送信する必要があります。
ii. Otherwise, the frame MUST be sent on all tunnels in the OIF list.
ii。それ以外の場合、フレームはOIFリストのすべてのトンネルに送信する必要があります。
c. The frame MUST be sent to the local L3 routing instance by being sent up the IRB interface of BD1. It MUST NOT be sent up any other IRB interfaces.
c. フレームは、BD1のIRBインターフェイスを送信することにより、ローカルL3ルーティングインスタンスに送信する必要があります。他のIRBインターフェイスを送信してはなりません。
2. The frame was received by PE1 over a tunnel from another PE. (See Section 3.2 for the rules to determine the apparent source BD of a packet received from another PE. Note that if PE1 is not attached to the source BD, it will regard the SBD as the apparent source BD.)
2. フレームは、別のPEからトンネルを介してPE1によって受信されました。（別のPEから受信したパケットの見かけのソースBDを決定するためのルールについては、セクション3.2を参照してください。PE1がソースBDに添付されていない場合、SBDは見かけのソースBDと見なすことに注意してください。）
a. The frame MUST be sent on all local ACs in the OIF list that connect to BD1 and that are eligible (per Section 4.1.2.1) to receive the frame.
a. フレームを受信するには、BD1に接続し、対象となる（セクション4.1.2.1ごとに）bd1に接続するOIFリストのすべてのローカルACSでフレームを送信する必要があります。
b. The frame MUST be sent up the IRB interface of the apparent source BD. (Note that this may be the SBD.) The frame MUST NOT be sent up any other IRB interfaces.
b. フレームは、見かけのソースBDのIRBインターフェイスに送信する必要があります。（これはSBDである可能性があることに注意してください。）フレームを他のIRBインターフェースに送信してはなりません。
c. If PE1 is not an AR-REPLICATOR, it MUST NOT send the frame to any other EVPN PEs. However, if PE1 is an AR-REPLICATOR, it MUST send the frame to all tunnels in the OIF list, except for the tunnel over which the frame was received.
c. PE1がAR-Replicatorでない場合、フレームを他のEVPN PEに送信してはなりません。ただし、PE1がAR-Replicatorである場合、フレームが受信されたトンネルを除き、OIFリスト内のすべてのトンネルにフレームを送信する必要があります。
3. The frame was received by PE1 from the BD1 IRB interface (i.e., the frame has been transmitted by PE1's L3 routing instance down the BD1 IRB interface), and BD1 is NOT the SBD.
3. フレームはBD1 IRBインターフェイスからPE1によって受信されました（つまり、フレームはBD1 IRBインターフェイスの下にPE1のL3ルーティングインスタンスによって送信されました）、BD1はSBDではありません。
a. The frame MUST be sent on all local ACs in the OIF list that are eligible, as per Section 4.1.2.1, to receive the frame.
a. フレームを受信するには、セクション4.1.2.1に従って、対象となるOIFリストのすべてのローカルACSでフレームを送信する必要があります。
b. The frame MUST NOT be sent to any other EVPN PEs.
b. フレームを他のEVPN PEに送信してはなりません。
c. The frame MUST NOT be sent up any IRB interfaces.
c. フレームをIRBインターフェイスに送信してはなりません。
4. The frame was received from the SBD IRB interface (i.e., has been transmitted by PE1's L3 routing instance down the SBD IRB interface).
4. フレームはSBD IRBインターフェイスから受信されました（つまり、SBD IRBインターフェイスの下にPE1のL3ルーティングインスタンスによって送信されました）。
a. The frame MUST be sent on all tunnels in the OIF list. This causes the frame to be delivered to any other EVPN PEs that have interest in it.
a. フレームは、OIFリストのすべてのトンネルに送信する必要があります。これにより、フレームは関心のある他のEVPN PEに配信されます。
b. The frame MUST NOT be sent on any local ACs.
b. フレームをローカルACSで送信してはなりません。
c. The frame MUST NOT be sent up any IRB interfaces.
c. フレームをIRBインターフェイスに送信してはなりません。
If an EVPN PE is performing IGMP/MLD procedures on the ACs of a given BD, it processes those messages at Layer 2 to help form the Layer 2 multicast state. It also sends those messages up that BD's IRB interface to the L3 routing instance of a particular Tenant Domain. This causes the (C-S,C-G) or (C-*,C-G) L3 state to be created/ updated.
EVPN PEが特定のBDのACSでIGMP/MLD手順を実行している場合、レイヤー2でそれらのメッセージを処理してレイヤー2マルチキャスト状態を形成します。また、これらのメッセージを、BDのIRBインターフェイスを特定のテナントドメインのL3ルーティングインスタンスに送信します。これにより、（c-s、c-g）または（c-*、c-g）L3状態が作成/更新されます。
A Layer 3 multicast state has both an Input Interface (IIF) and an OIF list.
レイヤー3マルチキャスト状態には、入力インターフェイス（IIF）とOIFリストの両方があります。
For a (C-S,C-G) state, if the source BD is present on the PE, the IIF is set to the IRB interface that attaches to that BD. Otherwise, the IIF is set to the SBD IRB interface.
A（C-S、C-G）状態の場合、ソースBDがPEに存在する場合、IIFはそのBDに付着するIRBインターフェイスに設定されます。それ以外の場合、IIFはSBD IRBインターフェイスに設定されています。
For (C-*,C-G) states, traffic can arrive from any BD, so the IIF needs to be set to a wildcard value meaning "any IRB interface".
（c-*、c-g）状態の場合、トラフィックは任意のBDから到着する可能性があるため、IIFは「任意のIRBインターフェイス」を意味するワイルドカード値に設定する必要があります。
The OIF list of these states includes one or more of the IRB interfaces of the Tenant Domain. In general, maintenance of the OIF list does not require any EVPN-specific procedures. However, there is one EVPN-specific rule:
これらの状態のOIFリストには、テナントドメインの1つ以上のIRBインターフェイスが含まれています。一般に、OIFリストのメンテナンスでは、EVPN固有の手順は必要ありません。ただし、EVPN固有のルールが1つあります。
If the IIF is one of the IRB interfaces (or the wildcard meaning "any IRB interface"), then the SBD IRB interface MUST NOT be added to the OIF list. Traffic originating from within a particular EVPN Tenant Domain must not be sent down the SBD IRB interface, as such traffic has already been distributed to all EVPN PEs attached to that Tenant Domain.
IIFがIRBインターフェイスの1つ（または「任意のIRBインターフェイス」を意味するワイルドカード）の場合、SBD IRBインターフェイスをOIFリストに追加してはなりません。特定のEVPNテナントドメイン内から発信されるトラフィックは、そのようなトラフィックがすでにそのテナントドメインに接続されているすべてのEVPN PEに分配されているため、SBD IRBインターフェイスを送信してはなりません。
Please also see Section 6.1.1, which states a modification of this rule for the case where OISM is interworking with external Layer 3 multicast routing.
また、OISMが外部層3マルチキャストルーティングと互換性がある場合のこの規則の変更を示すセクション6.1.1も参照してください。
It is possible that a given Tenant Domain will be attached to both OISM PEs and non-OISM PEs. Inter-subnet IP multicast should be possible and fully functional even if not all PEs attaching to a Tenant Domain can be upgraded to support OISM functionality.
特定のテナントドメインがOISM PESと非OISM PEの両方に接続される可能性があります。テナントドメインに付着するすべてのPEをアップグレードしてOISM機能をサポートできる場合でも、サブネット間IPマルチキャストは可能であり、完全に機能するはずです。
Note that the non-OISM PEs are not required to have IRB support or support for [RFC9251]. However, it is advantageous for the non-OISM PEs to support [RFC9251].
非オームPESは、[RFC9251]のIRBサポートまたはサポートを必要としないことに注意してください。ただし、非オイズムPESが[RFC9251]をサポートすることが有利です。
In this section, we will use the following terminology:
このセクションでは、次の用語を使用します。
PE-S:
PE-S：
The ingress PE for an (S,G) flow.
（s、g）フローの侵入PE。
PE-R:
PE-R：
An egress PE for an (S,G) flow.
（s、g）フローの出力PE。
BD-S:
BD-S：
The source BD for an (S,G) flow. PE-S must have one or more ACs attached to BD-S, at least one of which attaches to host S.
（s、g）フローのソースBD。PE-Sには、BD-Sに1つ以上のACが接続されている必要があり、そのうちの少なくとも1つはホストSに付着します。
BD-R:
BD-R：
A BD that contains a host interested in the flow. The host is attached to PE-R via an AC that belongs to BD-R.
フローに興味のあるホストを含むBD。ホストは、BD-Rに属するACを介してPE-Rに接続されています。
To allow OISM PEs to interwork with non-OISM PEs, a given Tenant Domain needs to contain one or more IP Multicast Gateways (IPMGs). An IPMG is an OISM PE with special responsibilities regarding the interworking between OISM and non-OISM PEs.
OISM PESが非OISM PESと相互作用できるようにするには、特定のテナントドメインには、1つ以上のIPマルチキャストゲートウェイ（IPMG）を含める必要があります。IPMGは、OISMと非オイズムPEの間の相互作用に関する特別な責任を持つOISM PEです。
If a PE is functioning as an IPMG, it MUST signal this fact by setting the IPMG flag in the Multicast Flags EC that it attaches to its IMET routes. An IPMG SHOULD attach this EC, with the IPMG flag set, to all IMET routes it originates. Furthermore, if PE1 imports any IMET route from PE2 that has the EC present with the IPMG flag set, then the PE1 will assume that PE2 is an IPMG.
PEがIPMGとして機能している場合、IMETルートに付着するマルチキャストフラグECにIPMGフラグを設定することにより、この事実を示す必要があります。IPMGは、IPMGフラグが設定されたこのECを、発信するすべてのIMETルートに添付する必要があります。さらに、PE1がECにIPMGフラグセットに存在するPE2からIMETルートをインポートする場合、PE1はPE2がIPMGであると仮定します。
An IPMG Designated Forwarder (IPMG-DF) selection procedure is used to ensure that there is exactly one active IPMG-DF for any given BD at any given time. Details of the IPMG-DF selection procedure are in Section 5.1. The IPMG-DF for a given BD, say BD-S, has special functions to perform when it receives (S,G) frames on that BD:
IPMG指定されたフォワーダー（IPMG-DF）選択手順を使用して、特定のBDに対していつでも1つのアクティブなIPMG-DFが1つあることを確認します。IPMG-DF選択手順の詳細は、セクション5.1にあります。特定のBDのIPMG-DF、たとえばBD-Sには、そのBDで（S、G）フレームを受信したときに実行する特別な機能があります。
* If the frames are from a non-OISM PE-S:
* フレームが非オイズムPE-Sからのものである場合：
- The IPMG-DF forwards them to OISM PEs that do not attach to BD-S but have interest in (S,G).
- IPMG-DFは、それらをBD-Sに付着させず、（S、G）に関心を持っているOism PESに転送します。
Note that OISM PEs that do attach to BD-S will have received the frames on the BUM tunnel from the non-OISM PE-S.
BD-Sに付着するOISM PESは、非オームPE-Sからバムトンネルのフレームを受信していることに注意してください。
- The IPMG-DF forwards them to non-OISM PEs that have interest in (S,G) on ACs that do not belong to BD-S.
- IPMG-DFは、BD-Sに属さないACSで（S、G）に関心のある非オイズムPEに転送します。
Note that if a non-OISM PE has multiple BDs (other than BD-S) with interest in (S,G), it will receive one copy of the frame for each such BD. This is necessary because the non-OISM PEs cannot move IP multicast traffic from one BD to another.
非オイズムPEに（s、g）に関心を持つ複数のBD（BD-S以外）がある場合、そのようなBDごとにフレームのコピーが1つ受け取られることに注意してください。非オームPESは、IPマルチキャストトラフィックをあるBDから別のBDに移動できないため、これが必要です。
* If the frames are from an OISM PE, the IPMG-DF forwards them to non-OISM PEs that have interest in (S,G) on ACs that do not belong to BD-S.
* フレームがOISM PEからのものである場合、IPMG-DFは、BD-Sに属さないACSで（S、G）に関心のある非OISM PEに転送します。
If a non-OISM PE has interest in (S,G) on an AC belonging to BD-S, it will have received a copy of the (S,G) frame, encapsulated for BD-S, from the OISM PE-S (see Section 3.2.2). If the non-OISM PE has interest in (S,G) on one or more ACs belonging to BD-R1,...,BD-Rk where the BD-Ri are distinct from BD-S, the IPMG-DF needs to send it a copy of the frame for each BD-Ri.
非オームPEがBD-Sに属するACで（S、G）に関心がある場合、oism pe-sからBD-Sにカプセル化された（s、g）フレームのコピーを受け取ります。（セクション3.2.2を参照）。非オオズムPEがBD-R1、...、BD-RKに属する1つ以上のACSに（S、G）に関心がある場合、BD-RIがBD-Sとは異なる場合、IPMG-DFは各BD-RIのフレームのコピーを送信します。
If an IPMG receives a frame on a BD for which it is not the IPMG-DF, it just follows normal OISM procedures.
IPMGがBDでIPMG-DFではないフレームを受信した場合、通常のOISM手順に従うだけです。
This section specifies several sets of procedures:
このセクションでは、いくつかの手順セットを指定します。
* the procedures that the IPMG-DF for a given BD needs to follow when receiving, on that BD, an IP multicast frame from a non-OISM PE;
* 特定のBDのIPMG-DFが、そのBDで、非OISM PEからのIPマルチキャストフレームを受信するときに従う必要がある手順。
* the procedures that the IPMG-DF for a given BD needs to follow when receiving, on that BD, an IP multicast frame from an OISM PE; and
* 特定のBDのIPMG-DFが、そのBDで、OISM PEからのIPマルチキャストフレームを受信するときに従う必要がある手順。そして
* the procedures that an OISM PE needs to follow when receiving, on a given BD, an IP multicast frame from a non-OISM PE, when the OISM PE is not the IPMG-DF for that BD.
* OISM PEがそのBDのIPMG-DFではない場合、OSISM PEが特定のBDで、非OISM PEからIPマルチキャストフレームを受信するときに従う必要がある手順。
To enable OISM/non-OISM interworking in a given Tenant Domain, the Tenant Domain MUST have some EVPN PEs that can function as IPMGs. An IPMG must be configured with the SBD. It must also be configured with every BD of the Tenant Domain that exists on any of the non-OISM PEs of that domain. (Operationally, it may be simpler to configure the IPMG with all the BDs of the Tenant Domain.)
特定のテナントドメインでOISM/非オイズムインターワーキングを可能にするには、テナントドメインにはIPMGSとして機能できるEVPN PESが必要です。IPMGはSBDで構成する必要があります。また、そのドメインの非オイズムPEのいずれかに存在するテナントドメインのすべてのBDで構成する必要があります。（運用上、テナントドメインのすべてのBDSでIPMGを構成する方が簡単かもしれません。）
Of course, a non-OISM PE only needs to be configured with BDs for which it has ACs. An OISM PE that is not an IPMG only needs to be configured with the SBD and with the BDs for which it has ACs.
もちろん、非オイズムPEは、ACSを持つBDSで構成する必要があります。IPMGではないOISM PEは、SBDおよびACSを搭載したBDSでのみ構成する必要があります。
An IPMG MUST originate a wildcard SMET route (with (C-*,C-*) in the NLRI) for each BD in the Tenant Domain. This will cause it to receive all the IP multicast traffic that is sourced in the Tenant Domain. Note that non-OISM nodes that do not support [RFC9251] will send all the multicast traffic from a given BD to all PEs attached to that BD, even if those PEs do not originate a SMET route.
IPMGは、テナントドメインの各BDのワイルドカードスメットルート（NLRIに（c-*、c-*）を備えている）を発信する必要があります。これにより、テナントドメインに供給されているすべてのIPマルチキャストトラフィックを受信します。[RFC9251]をサポートしていない非オイズムノードは、特定のBDからすべてのマルチキャストトラフィックを、それらのPEがSMETルートを発生させなくても、そのBDに付随するすべてのPEに送信することに注意してください。
The interworking procedures vary somewhat depending upon whether packets are transmitted from PE to PE via IR or via P2MP tunnels. In this section, we do not consider the use of BIER due to the low likelihood of there being a non-OISM PE that supports BIER.
インターワーキング手順は、パケットがIRを介してPEからPEにPEに送信されるか、P2MPトンネルを介して送信されるかによって多少異なります。このセクションでは、ビアをサポートする非オイズムPEがある可能性が低いため、ビアの使用を考慮しません。
Every PE that is eligible for selection as an IPMG-DF for a particular BD originates both an IMET route for that BD and an SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry a Multicast Flags EC with the IPMG flag set.
特定のBDのIPMG-DFとして選択できるすべてのPEは、そのBDとSBD-IMETルートのIMETルートの両方を発生します。セクション5で述べたように、これらのSBD-IMETルートは、IPMGフラグセットを備えたマルチキャストフラグECを搭載しています。
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF Election EC and its use is specified in [RFC8584]. When the route is originated, the AC-DF bit in the DF Election EC SHOULD NOT be set. This bit is not used when selecting an IPMG-DF, i.e., it MUST be ignored by the receiver of an SBD-IMET route.
これらのSBD-IMETルートは、DF選挙ECも搭載する必要があります。DF選挙ECとその使用は[RFC8584]で指定されています。ルートが発信される場合、DF選挙ECのAC-DFビットを設定しないでください。このビットは、IPMG-dfを選択するときは使用されません。つまり、SBD-IMETルートの受信機によって無視する必要があります。
In the context of a given Tenant Domain, to select the IPMG-DF for a particular BD, say BD1, the IPMGs of the Tenant Domain perform the following procedures:
特定のテナントドメインのコンテキストでは、特定のBDのIPMG-DFを選択するために、たとえばBD1、テナントドメインのIPMGSは次の手順を実行します。
* From the set of received SBD-IMET routes for the given Tenant Domain, determine the candidate set of PEs that support IPMG functionality for that domain.
* 指定されたテナントドメインの受信したSBD-IMETルートのセットから、そのドメインのIPMG機能をサポートするPESの候補セットを決定します。
* From that candidate set, eliminate any PEs from which an IMET route for BD1 has not been received.
* その候補セットから、BD1のIMETルートが受信されていないPESを排除します。
* Select a DF election algorithm as specified in [RFC8584]. Some of the possible algorithms can be found, e.g., in [RFC8584], [RFC7432], and [EVPN-DF].
* [RFC8584]で指定されているDF選挙アルゴリズムを選択します。可能なアルゴリズムのいくつかは、[RFC8584]、[RFC7432]、および[EVPN-DF]など、たとえば見つけることができます。
* Apply the DF election algorithm (see [RFC8584]) to the candidate set of PEs. The winner becomes the IPMG-DF for BD1.
* DF選挙アルゴリズム（[RFC8584]を参照）をPESの候補セットに適用します。勝者はBD1のIPMG-DFになります。
Note that even if a given PE supports MEG (Section 6.1.2) and/or PEG (Section 6.1.4) functionality, as well as IPMG functionality, its SBD-IMET routes carry only one DF Election EC.
特定のPEがMEG（セクション6.1.2）および/またはPEG（セクション6.1.4）機能、およびIPMG機能をサポートしている場合でも、SBD-IMETルートは1つのDF選挙ECのみを搭載していることに注意してください。
The procedures of this section are used when IR is used to transmit packets from one PE to another.
このセクションの手順は、IRを使用してパケットをあるPEから別のPEに送信する場合に使用されます。
When a non-OISM PE-S transmits a multicast frame from BD-S to another PE, say PE-R, PE-S will use the encapsulation specified in the BD-S IMET route that was originated by PE-R. This encapsulation will include the label that appears in the MPLS Label field of the PTA of the IMET route. If the tunnel type is VXLAN, the label is actually a Virtual Network Identifier (VNI); for other tunnel types, the label is an MPLS label. In either case, the frames are transmitted with a label that was assigned to a particular BD by the PE-R to which the frame is being transmitted.
非オームPE-SがBD-Sから別のPEにマルチキャストフレームを送信すると、PE-R、PE-SがPE-Rから発信されたBD-S IMETルートで指定されたカプセル化を使用します。このカプセル化には、IMETルートのPTAのMPLSラベルフィールドに表示されるラベルが含まれます。トンネルタイプがVXLANの場合、ラベルは実際には仮想ネットワーク識別子（VNI）です。他のトンネルタイプの場合、ラベルはMPLSラベルです。どちらの場合でも、フレームは、フレームが送信されているPE-Rによって特定のBDに割り当てられたラベルで送信されます。
To support OISM/non-OISM interworking, an OISM PE-R MUST originate, for each of its BDs, both an IMET route and an (C-*,C-*) S-PMSI A-D route. Note that even when IR is being used, interworking between OISM and non-OISM PEs requires the OISM PEs to follow the rules of Section 3.2.5.2, as modified below.
OISM/非オイズムの相互作用をサポートするには、IMETルートと（C - *、C-*）S-PMSI A-Dルートの両方で、BDSのそれぞれについて、OISM PE-Rが発生する必要があります。IRが使用されている場合でも、OISMと非オイズムPESの間の交流には、以下に変更されるように、セクション3.2.5.2のルールに従うことがOISAM PESに従う必要があることに注意してください。
Non-OISM PEs will not understand S-PMSI A-D routes. So when a non-OISM PE-S transmits an IP multicast frame with a particular source BD to an IPMG, it encapsulates the frame using the label specified in that IPMG's BD-S IMET route. (This is just the procedure of [RFC7432].)
非オイズムPESはS-PMSI A-Dルートを理解しません。したがって、非オームPE-Sが特定のソースBDを使用してIPマルチキャストフレームをIPMGに送信すると、そのIPMGのBD-S IMETルートで指定されたラベルを使用してフレームをカプセル化します。（これは[RFC7432]の手順にすぎません。）
The (C-*,C-*) S-PMSI A-D route originated by a given OISM PE will have a PTA that specifies IR.
（c - *、c-*）s-pmsi a-dルートは、特定のoism peによって発生するルートに、irを指定するPTAがあります。
* If MPLS tunneling is being used, the MPLS Label field SHOULD contain a non-zero value, and the LIR flag SHOULD be zero. (The case where the MPLS Label field is zero or the LIR flag is set is outside the scope of this document.)
* MPLSトンネルが使用されている場合、MPLSラベルフィールドにはゼロ以外の値が含まれ、LIRフラグはゼロにする必要があります。（MPLSラベルフィールドがゼロであるか、LIRフラグが設定されている場合、このドキュメントの範囲外です。）
* If the tunnel encapsulation is VXLAN, the MPLS Label field MUST contain a non-zero value, and the LIR flag MUST be zero.
* トンネルのカプセル化がVXLANの場合、MPLSラベルフィールドにはゼロ以外の値が含まれている必要があり、LIRフラグはゼロでなければなりません。
When an OISM PE-S transmits an IP multicast frame to an IPMG, it will use the label specified in that IPMG's (C-*,C-*) S-PMSI A-D route.
OISM PE-SがIPマルチキャストフレームをIPMGに送信すると、そのIPMG（C - *、C-*）S-PMSI A-Dルートで指定されたラベルを使用します。
When a PE originates both an IMET route and a (C-*,C-*) S-PMSI A-D route, the values of the MPLS Label field in the respective PTAs must be distinct. Further, each MUST map uniquely (in the context of the originating PE) to the route's BD.
PEがIMETルートとA（C-*、C-*）S-PMSI A-Dルートの両方を発信する場合、それぞれのPTAのMPLSラベルフィールドの値は異なる必要があります。さらに、それぞれが（発生するPEのコンテキストで）ルートのBDに一意にマッピングする必要があります。
As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame can always tell by the label whether the frame's ingress PE is an OISM PE or a non-OISM PE. When an IPMG receives a VXLAN-encapsulated IP multicast frame, it may need to determine the identity of the ingress PE from the outer IP encapsulation; it can then determine whether the ingress PE is an OISM PE or a non-OISM PE by looking at the IMET route from that PE.
その結果、MPLSでカプセル化されたIPマルチキャストフレームを受信するIPMGは、フレームの侵入PEがOISM PEであるか非オームPEであるかを常にラベルで確認できます。IPMGがVXLANにカプセル化されたIPマルチキャストフレームを受信する場合、外部IPカプセル化からの侵入PEのIDを決定する必要がある場合があります。その後、そのPEからのIMETルートを見ることにより、侵入PEがOism PEまたは非オイズムPEであるかどうかを判断できます。
Suppose an IPMG receives an IP multicast frame from another EVPN PE in the Tenant Domain and the IPMG is not the IPMG-DF for the frame's source BD. Then, the IPMG performs only the ordinary OISM functions; it does not perform the IPMG-specific functions for that frame. In the remainder of this section, when we discuss the procedures applied by an IPMG when it receives an IP multicast frame, we are presuming that the source BD of the frame is a BD for which the IPMG is the IPMG-DF.
IPMGがテナントドメインの別のEVPN PEからIPマルチキャストフレームを受信し、IPMGがフレームのソースBDのIPMG-DFではないと仮定します。次に、IPMGは通常のOISM関数のみを実行します。そのフレームのIPMG固有の関数は実行されません。このセクションの残りの部分では、IPマルチキャストフレームを受信したときにIPMGによって適用される手順について説明するとき、フレームのソースBDはIPMGがIPMG-DFであるBDであると推測しています。
We have two basic cases to consider: (1) a frame's ingress PE is a non-OISM node and (2) a frame's ingress PE is an OISM node.
（1）フレームの侵入PEは非オームノードであり、（2）フレームの侵入PEはOISMノードです。
In this case, a non-OISM PE, say PE-S, has received an (S,G) multicast frame over an AC that is attached to a particular BD, say BD-S. By virtue of normal EVPN procedures, PE-S has sent a copy of the frame to every PE-R (both OISM and non-OISM) in the Tenant Domain that is attached to BD-S. If the non-OISM node supports [RFC9251], only PEs that have expressed interest in (S,G) receive the frame. The IPMG will have expressed interest via a (C-*,C-*) SMET route and thus receives the frame.
この場合、PE-Sなどの非オイズムPEは、特定のBDに接続されているACに（s、g）マルチキャストフレームを受け取りました、たとえばBD-S。通常のEVPN手順により、PE-Sは、BD-Sに接続されているテナントドメインのすべてのPE-R（OISMと非OISMの両方）にフレームのコピーを送信しました。非オームノードが[RFC9251]をサポートしている場合、（s、g）に関心を表明したPEのみがフレームを受け取ります。IPMGは、（C - *、C-*）SMETルートを介して関心を表明し、フレームを受け取ります。
Any OISM PE (including an IPMG) receiving the frame will apply normal OISM procedures. As a result, it will deliver the frame to any of its local ACs (in BD-S or in any other BD) that have interest in (S,G).
フレームを受信するOISMPE（IPMGを含む）は、通常のOISM手順を適用します。その結果、（s、g）に関心のあるローカルACS（BD-Sまたは他のBD）のいずれかにフレームを配信します。
An OISM PE that is also the IPMG-DF for a particular BD, say BD-S, has additional procedures that it applies to frames received on BD-S from non-OISM PEs:
特定のBDのIPMG-DFでもあるOISM PE、たとえば、BD-Sには、非OISM PESからBD-Sで受信したフレームに適用される追加手順があります。
1. When the IPMG-DF for BD-S receives an (S,G) frame from a non-OISM node, it MUST forward a copy of the frame to every OISM PE that is NOT attached to BD-S but has interest in (S,G). The copy sent to a given OISM PE-R must carry the label that PE-R has assigned to the SBD in an S-PMSI A-D route. The IPMG MUST NOT do any IP processing of the frame's IP payload. TTL decrement and other IP processing will be done by PE-R, per the normal OISM procedures. There is no need for the IPMG to include an ESI label in the frame's tunnel encapsulation, because it is already known that the frame's source BD has no presence on PE-R. There is also no need for the IPMG to modify the frame's MAC SA.
1. BD-SのIPMG-dfが非OISMノードから（s、g）フレームを受信する場合、BD-Sに添付されていないが関心のあるすべてのOISMPEにフレームのコピーを転送する必要があります。、g）。特定のOISM PE-Rに送信されたコピーは、SPMSI A-DルートでPE-RがSBDに割り当てたラベルを運ぶ必要があります。IPMGは、フレームのIPペイロードのIP処理を実行してはなりません。TTLの減少およびその他のIP処理は、通常のOISM手順に従ってPE-Rによって行われます。フレームのソースBDがPE-Rに存在しないことがすでに知られているため、IPMGがフレームのトンネルカプセル化にESIラベルを含める必要はありません。また、IPMGがフレームのMac SAを変更する必要はありません。
2. In addition, when the IPMG-DF for BD-S receives an (S,G) frame from a non-OISM node, it may need to forward copies of the frame to other non-OISM nodes. Before it does so, it MUST decapsulate the (S,G) packet and do the IP processing (e.g., TTL decrement). Suppose PE-R is a non-OISM node that has an AC to BD-R, where BD-R is not the same as BD-S, and that AC has interest in (S,G). The IPMG must then encapsulate the (S,G) packet (after the IP processing has been done) in an Ethernet header. The MAC SA field will have the MAC address of the IPMG's IRB interface for BD-R. The IPMG then sends the frame to PE-R. The tunnel encapsulation will carry the label that PE-R advertised in its IMET route for BD-R. There is no need to include an ESI label, as the source and destination BDs are known to be different.
2. さらに、BD-SのIPMG-DFが非OISMノードから（s、g）フレームを受信する場合、フレームのコピーを他の非オイズムノードに転送する必要がある場合があります。その前に、（s、g）パケットを脱カプセル化し、IP処理を実行する必要があります（たとえば、TTLの減少）。PE-RがBD-RからBD-Rを持つ非OISMノードであり、BD-RはBD-Sと同じではなく、ACが（S、G）に関心があると仮定します。IPMGは、イーサネットヘッダーで（s、g）パケット（IP処理が完了した後）をカプセル化する必要があります。MAC SAフィールドには、BD-RのIPMGのIRBインターフェイスのMACアドレスがあります。IPMGはフレームをPE-Rに送信します。トンネルのカプセル化には、BD-RのIMETルートでPE-Rが宣伝されているラベルが付いています。ソースと宛先BDSは異なることが知られているため、ESIラベルを含める必要はありません。
Note that if a non-OISM PE-R has several BDs (other than BD-S) with local ACs that have interest in (S,G), the IPMG will send it one copy for each such BD. This is necessary because the non-OISM PE cannot move packets from one BD to another.
非OISM PE-Rに（s、g）に関心のあるローカルACSを備えたいくつかのBD（BD-S以外）がある場合、IPMGはそのようなBDごとに1つのコピーを送信することに注意してください。これは、非オイズムPEがパケットをあるBDから別のパケットに移動できないため、必要です。
There may be deployment scenarios in which every OISM PE is configured with every BD that is present on any non-OISM PE. In such scenarios, the procedures of item 1 above will not actually result in the transmission of any packets. Hence, if it is known a priori that this deployment scenario exists for a given Tenant Domain, the procedures of item 1 above can be disabled.
すべてのOISM PEが、すべての非オームPEに存在するすべてのBDで構成される展開シナリオがある場合があります。このようなシナリオでは、上記の項目1の手順では、実際にはパケットの送信が生じません。したがって、この展開シナリオが特定のテナントドメインに対して存在することが先験的に知られている場合、上記の項目1の手順を無効にすることができます。
In this case, an OISM PE, say PE-S, has received an (S,G) multicast frame over an AC that attaches to a particular BD, say BD-S.
この場合、PE-SなどのOism PEは、特定のBDに付着するACに（S、G）マルチキャストフレームを受け取りました。たとえば、BD-S。
By virtue of receiving all the IMET routes for BD-S, PE-S will know all the PEs attached to BD-S. By virtue of normal OISM procedures:
BD-SのすべてのIMETルートを受け取ることにより、PE-SはBD-Sに接続されたすべてのPEを知ることができます。通常のOISM手順により：
* PE-S will send a copy of the frame to every OISM PE-R (including the IPMG) in the Tenant Domain that is attached to BD-S and has interest in (S,G). The copy sent to a given PE-R carries the label that the PE-R has assigned to BD-S in its (C-*,C-*) S-PMSI A-D route.
* PE-Sは、BD-Sに取り付けられ、（S、G）に関心のあるテナントドメインのすべてのOISM PE-R（IPMGを含む）にフレームのコピーを送信します。特定のPE-Rに送信されたコピーには、PE-RがBD-Sに（C - *、C-*）S-PMSI A-Dルートに割り当てたラベルが付いています。
* PE-S will also transmit a copy of the (S,G) frame to every OISM PE-R that has interest in (S,G) but is not attached to BD-S. The copy will contain the label that the PE-R has assigned to the SBD. (As specified in Section 5.2.1, an IPMG is assumed to have indicated interest in all multicast flows.)
* PE-Sは、（s、g）フレームのコピーを（s、g）に関心があるが、BD-Sには添付されていないすべてのOISM PE-Rに送信します。コピーには、PE-RがSBDに割り当てたラベルが含まれます。（セクション5.2.1で指定されているように、IPMGはすべてのマルチキャストフローに関心を示していると想定されています。）
* PE-S will also transmit a copy of the (S,G) frame to every non-OISM PE-R that is attached to BD-S. It does this using the label advertised by that PE-R in its IMET route for BD-S.
* PE-Sは、BD-Sに接続されているすべての非オイズムPE-Rに（S、G）フレームのコピーを送信します。これは、BD-SのIMETルートでそのPE-Rによって宣伝されたラベルを使用して行います。
The PE-Rs follow their normal procedures. An OISM PE that receives the (S,G) frame on BD-S applies the OISM procedures to deliver the frame to its local ACs as necessary. A non-OISM PE that receives the (S,G) frame on BD-S delivers the frame only to its local BD-S ACs as necessary.
PE-Rは通常の手順に従います。BD-Sで（S、G）フレームを受信するOISM PEは、必要に応じてローカルACSにフレームを配信するためにOISM手順を適用します。BD-Sで（s、g）フレームを受信する非オイズムPEは、必要に応じてローカルBD-S ACSにフレームを提供します。
Suppose that a non-OISM PE-R has interest in (S,G) on a BD that is different than BD-S, say BD-R. If the non-OISM PE-R is attached to BD-S, the OISM PE-S will send it the original (S,G) multicast frame, but the non-OISM PE-R will not be able to send the frame to ACs that are not in BD-S. If PE-R is not even attached to BD-S, the OISM PE-S will not send it a copy of the frame at all, because PE-R is not attached to the SBD. In these cases, the IPMG needs to relay the (S,G) multicast traffic from OISM PE-S to non-OISM PE-R.
BD-Rは、BD-Rとは異なるBDに、非オームPE-Rが（S、G）に関心があると仮定します。非オイズムPE-RがBD-Sに接続されている場合、OISM PE-Sはオリジナル（S、G）マルチキャストフレームを送信しますが、非オームPE-Rはフレームを送信できません。BD-SにないACS。PE-RがBD-Sにさえ付着していない場合、OISM PE-Sは、PE-RがSBDに接続されていないため、フレームのコピーをまったく送信しません。これらの場合、IPMGは（S、G）マルチキャストトラフィックをOISM PE-Sから非OISM PE-Rに中継する必要があります。
When the IPMG-DF for BD-S receives an (S,G) frame from an OISM PE-S, it has to forward it to every non-OISM PE-R that has interest in (S,G) on a BD-R that is different than BD-S. The IPMG MUST decapsulate the IP multicast packet, do the IP processing, re-encapsulate it for BD-R (changing the MAC SA to the IPMG's own MAC address for BD-R), and send a copy of the frame to PE-R. Note that a given non-OISM PE-R will receive multiple copies of the frame if it has multiple BDs on which there is interest in the frame.
BD-SのIPMG-DFがOISM PE-Sから（S、G）フレームを受信する場合、BD-で（S、g）に関心を持っているすべての非オイズムPE-Rに転送する必要があります。rそれはBD-Sとは異なります。IPMGは、IPマルチキャストパケットを脱カプセル化し、IP処理を実行し、BD-Rの場合（MAC SAをBD-RのIPMG独自のMACアドレスに変更する）ために再カプセル化し、フレームのコピーをPE-Rに送信する必要があります。与えられた非オームPE-Rは、フレームに関心がある複数のBDSがある場合、フレームの複数のコピーを受け取ることに注意してください。
When IR is used to distribute the multicast traffic among the EVPN PEs, the procedures described in Section 5.2 ensure that there will be no duplicate delivery of multicast traffic. That is, no egress PE will ever send a frame twice on any given AC. If P2MP tunnels are being used to distribute the multicast traffic, it is necessary to have additional procedures to prevent duplicate delivery.
IRを使用してEVPN PES間でマルチキャストトラフィックを配布する場合、セクション5.2で説明されている手順により、マルチキャストトラフィックの重複配信がないことが確認されます。つまり、GERSERS PEは、特定のACで2回フレームを送信することはありません。マルチキャストトラフィックの分布にP2MPトンネルが使用されている場合、配信の重複を防ぐために追加の手順が必要です。
At the present time, it is not clear that there will be a use case in which OISM nodes need to interwork with non-OISM nodes that use P2MP tunnels. If it is determined that there is such a use case, procedures for P2MP may be specified in a separate document.
現時点では、OISMノードがP2MPトンネルを使用する非OISMノードと対話する必要があるというユースケースがあることは明らかではありません。そのようなユースケースがあると判断された場合、P2MPの手順を別のドキュメントで指定することができます。
In this section, we discuss scenarios where a multicast source outside a given EVPN Tenant Domain sends traffic to receivers inside the domain (as well as, possibly, to receivers outside the domain). This requires the OISM procedures to interwork with various Layer 3 multicast routing procedures.
このセクションでは、特定のEVPNテナントドメインの外側のマルチキャストソースがドメイン内のレシーバーにトラフィックを送信する（およびおそらくドメイン外の受信機に）シナリオについて説明します。これには、さまざまなレイヤー3マルチキャストルーティング手順と対話するためのOISM手順が必要です。
In this section, we assume that the Tenant Domain is not being used as an intermediate transit network for multicast traffic; that is, we do not consider the case where the Tenant Domain contains multicast routers that will receive traffic from sources outside the domain and forward the traffic to receivers outside the domain. The transit scenario is considered in Section 7.
このセクションでは、テナントドメインがマルチキャストトラフィックの中間輸送ネットワークとして使用されていないと仮定します。つまり、テナントドメインにドメインの外側のソースからトラフィックを受け取り、ドメインの外側のレシーバーにトラフィックを転送するマルチキャストルーターが含まれている場合は考えません。トランジットシナリオはセクション7で検討されています。
We can divide the non-transit scenarios into two classes:
非輸送シナリオを2つのクラスに分割できます。
1. One or more of the EVPN PE routers provide the functionality needed to interwork with Layer 3 multicast routing procedures.
1. 1つ以上のEVPN PEルーターは、レイヤー3マルチキャストルーティング手順とのインターワークに必要な機能を提供します。
2. A single BD in the Tenant Domain contains external multicast routers (tenant multicast routers), and those tenant multicast routers are used to interwork, on behalf of the entire Tenant Domain, with Layer 3 multicast routing procedures.
2. テナントドメインの単一のBDには、外部マルチキャストルーター（テナントマルチキャストルーター）が含まれており、これらのテナントマルチキャストルーターは、レイヤー3マルチキャストルーティング手順を備えたテナントドメイン全体に代わってインターワークに使用されます。
Sometimes it is necessary to interwork an EVPN Tenant Domain with an external Layer 3 multicast domain (the external domain), e.g., a PIM or MVPN domain. This is needed to allow EVPN tenant systems to receive multicast traffic from sources (external sources) outside the EVPN Tenant Domain. It is also needed to allow receivers (external receivers) outside the EVPN Tenant Domain to receive traffic from sources inside the Tenant Domain.
外部層3マルチキャストドメイン（外部ドメイン）、たとえばPIMまたはMVPNドメインを備えたEVPNテナントドメインとインターワークする必要がある場合があります。これは、EVPNテナントシステムがEVPNテナントドメインの外側のソース（外部ソース）からマルチキャストトラフィックを受信できるようにするために必要です。また、EVPNテナントドメインの外側のレシーバー（外部レシーバー）がテナントドメイン内のソースからトラフィックを受信できるようにする必要があります。
In order to allow interworking between an EVPN Tenant Domain and an external domain, one or more OISM PEs must be L3 Gateways. An L3 Gateway participates both in the OISM procedures and in the L3 multicast routing procedures of the external domain, as shown in the following figure.
EVPNテナントドメインと外部ドメイン間のインターワーキングを可能にするためには、1つ以上のOISM PESがL3ゲートウェイでなければなりません。次の図に示すように、L3ゲートウェイは、OISM手順と外部ドメインのL3マルチキャストルーティング手順の両方に参加します。
src1 rcvr1
| |
R1 RP R2
PIM/MVPN
Domain
+---+ +---+
-----|GW1|----------------------|GW2|----
+---+ +---+
| \ \ / / |
| \ \ / / |
BD1 BD2 SBD SBD BD2 BD1
EVPN Domain
SBD SBD
/ \
/ \
+---+ +---+
|PE1| |PE2|
+---+ +---+
| \ / |
BD1 BD2 BD2 BD1
| | | |
src2 rcvr2 src3 rcvr3
Figure 1: Interworking via OISM PEs
図1：OISM PESを介したインターワーキング
An L3 Gateway that has interest in receiving (S,G) traffic must be able to determine the best route to S. If an L3 Gateway has interest in (*,G), it must be able to determine the best route to G's RP. In these interworking scenarios, the L3 Gateway must be running a Layer 3 unicast routing protocol. Via this protocol, it imports unicast routes (either IP routes or VPN-IP routes) from routers other than EVPN PEs. And since there may be multicast sources inside the EVPN Tenant Domain, the EVPN PEs also need to export, either as IP routes or as VPN-IP routes (depending upon the external domain), unicast routes to those sources.
受信（s、g）トラフィックに関心のあるL3ゲートウェイは、Sへの最適なルートを決定できる必要があります。L3ゲートウェイが（*、g）に関心がある場合、GのRPへの最適なルートを決定できる必要があります。これらのインターワーキングシナリオでは、L3ゲートウェイはレイヤー3ユニキャストルーティングプロトコルを実行している必要があります。このプロトコルを介して、EVPN PE以外のルーターからユニキャストルート（IPルートまたはVPN-IPルート）をインポートします。また、EVPNテナントドメイン内にマルチキャストソースがある可能性があるため、EVPN PESは、IPルートまたはVPN-IPルート（外部ドメインに応じて）としてエクスポートする必要があります。
When selecting the best route to a multicast source or RP, an L3 Gateway might have a choice between an EVPN route and an IP/VPN-IP route. When such a choice exists, the L3 Gateway SHOULD always prefer the EVPN route. This will ensure that when traffic originates in the Tenant Domain and has a receiver in the Tenant Domain, the path to that receiver will remain within the EVPN Tenant Domain, even if the source is also reachable via a routed path. This also provides protection against sub-optimal routing that might occur if two EVPN PEs export IP/VPN-IP routes and each imports the other's IP/ VPN-IP routes.
マルチキャストソースまたはRPへの最適なルートを選択する場合、L3ゲートウェイはEVPNルートとIP/VPN-IPルートのどちらかを選択できます。このような選択が存在する場合、L3ゲートウェイは常にEVPNルートを好むはずです。これにより、トラフィックがテナントドメインに由来し、テナントドメインにレシーバーがある場合、そのレシーバーへのパスは、ルーティングされたパスを介してソースにも到達可能であっても、EVPNテナントドメイン内にとどまることが保証されます。これにより、2つのEVPN PESがIP/ VPN-IPルートをエクスポートし、それぞれが相手のIP/ VPN-IPルートをインポートする場合に発生する可能性のある準最適ルーティングに対する保護も提供します。
Section 4.2 discusses the way Layer 3 multicast states are constructed by OISM PEs. These Layer 3 multicast states have IRB interfaces as their IIF and OIF list entries and are the basis for interworking OISM with other Layer 3 multicast procedures such as MVPN or PIM. From the perspective of the Layer 3 multicast procedures running in a given L3 Gateway, an EVPN Tenant Domain is a set of IRB interfaces.
セクション4.2では、レイヤー3マルチキャスト状態がOISM PESによって構築される方法について説明します。これらのレイヤー3マルチキャスト状態は、IIFおよびOIFリストエントリとしてIRBインターフェイスを備えており、MVPNやPIMなどの他のレイヤー3マルチキャスト手順とOISMを操作するための基礎となります。特定のL3ゲートウェイで実行されているレイヤー3マルチキャスト手順の観点から、EVPNテナントドメインはIRBインターフェイスのセットです。
When interworking an EVPN Tenant Domain with an external domain, the L3 Gateway's Layer 3 multicast states will not only have IRB interfaces as IIF and OIF list entries but also other interfaces that lead outside the Tenant Domain. For example, when interworking with MVPN, the multicast states may have MVPN tunnels as well as IRB interfaces as IIF or OIF list members. When interworking with PIM, the multicast states may have PIM-enabled non-IRB interfaces as IIF or OIF list members.
EVPNテナントドメインを外部ドメインでインターワーキングする場合、L3 Gatewayのレイヤー3マルチキャスト状態には、IIFおよびOIFリストエントリとしてのIRBインターフェイスだけでなく、テナントドメインの外側につながる他のインターフェイスもあります。たとえば、MVPNと互換性がある場合、マルチキャスト状態には、IIFまたはOIFリストメンバーとしてMVPNトンネルやIRBインターフェイスがある場合があります。PIMと互換性がある場合、マルチキャスト状態には、IIFまたはOIFリストメンバーとしてPIM対応の非IRBインターフェイスがある場合があります。
As long as a Tenant Domain is not being used as an intermediate transit network for IP multicast traffic, it is not necessary to enable PIM on its IRB interfaces.
テナントドメインがIPマルチキャストトラフィックの中間トランジットネットワークとして使用されていない限り、IRBインターフェイスでPIMを有効にする必要はありません。
In general, an L3 Gateway has the following responsibilities:
一般に、L3ゲートウェイには次の責任があります。
* It exports, to the external domain, unicast routes to those multicast sources in the EVPN Tenant Domain that are locally attached to the L3 Gateway.
* 外部ドメインに、L3ゲートウェイに局所的に接続されているEVPNテナントドメインのマルチキャストソースへのユニキャストルートをエクスポートします。
* It imports, from the external domain, unicast routes to multicast sources that are in the external domain.
* 外部ドメインから、外部ドメインにあるマルチキャストソースにユニキャストルートにインポートします。
* It executes the procedures necessary to draw externally sourced multicast traffic that is of interest to locally attached receivers in the EVPN Tenant Domain. When such traffic is received, the traffic is sent down the IRB interfaces of the BDs on which the locally attached receivers reside.
* EVPNテナントドメインのローカルに接続されたレシーバーにとって興味深い外部から調達されたマルチキャストトラフィックを描画するために必要な手順を実行します。そのようなトラフィックが受信されると、トラフィックは、ローカルに接続されたレシーバーが存在するBDSのIRBインターフェイスを送信します。
One of the L3 Gateways in a given Tenant Domain becomes the DR for the SBD (see Section 6.1.2.4). This L3 Gateway has the following additional responsibilities:
特定のテナントドメインのL3ゲートウェイの1つは、SBDのDRになります（セクション6.1.2.4を参照）。このL3ゲートウェイには、次の追加の責任があります。
* It exports, to the external domain, unicast routes to multicast sources in the EVPN Tenant Domain that are not locally attached to any L3 Gateway.
* 外部ドメインに、L3ゲートウェイに局所的に接続されていないEVPNテナントドメインのマルチキャストソースへのユニキャストルートをエクスポートします。
* It imports, from the external domain, unicast routes to multicast sources that are in the external domain.
* 外部ドメインから、外部ドメインにあるマルチキャストソースにユニキャストルートにインポートします。
* It executes the procedures necessary to draw externally sourced multicast traffic that is of interest to receivers in the EVPN Tenant Domain that are not locally attached to an L3 Gateway. When such traffic is received, the traffic is sent down the SBD IRB interface. OISM procedures already described in this document will then ensure that the IP multicast traffic gets distributed throughout the Tenant Domain to any EVPN PEs that have interest in it. Thus, to an OISM PE that is not an L3 Gateway, the externally sourced traffic will appear to have been sourced on the SBD.
* L3ゲートウェイに局所的に接続されていないEVPNテナントドメインの受信機にとって興味深い外部からソースのマルチキャストトラフィックを描画するために必要な手順を実行します。そのようなトラフィックが受信されると、トラフィックがSBD IRBインターフェイスに送信されます。このドキュメントで既に説明されているOISM手順により、IPマルチキャストトラフィックがテナントドメイン全体で関心のあるEVPN PEに分配されるようになります。したがって、L3ゲートウェイではないOISM PEには、外部から調達されたトラフィックがSBDで調達されているように見えます。
In order for this to work, some special care is needed when an L3 Gateway creates or modifies a Layer 3 (*,G) multicast state. Suppose group G has both external sources (sources outside the EVPN Tenant Domain) and internal sources (sources inside the EVPN Tenant Domain). Section 4.2 states that when there are internal sources, the SBD IRB interface must not be added to the OIF list of the (*,G) state. Traffic from internal sources will already have been delivered to all the EVPN PEs that have interest in it. However, if the OIF list of the (*,G) state does not contain its SBD IRB interface, then traffic from external sources will not get delivered to other EVPN PEs.
これが機能するためには、L3ゲートウェイがレイヤー3（*、g）マルチキャスト状態を作成または変更する場合、特別な注意が必要です。グループGには、外部ソース（EVPNテナントドメインの外側のソース）と内部ソース（EVPNテナントドメイン内のソース）の両方があるとします。セクション4.2は、内部ソースがある場合、SBD IRBインターフェイスを（*、g）状態のOIFリストに追加してはならないことを示しています。内部ソースからのトラフィックは、すでに関心のあるすべてのEVPN PEに配信されています。ただし、（*、g）状態のOIFリストにSBD IRBインターフェイスが含まれていない場合、外部ソースからのトラフィックは他のEVPN PEに配信されません。
One way of handling this is the following. When an L3 Gateway receives (S,G) traffic that is from an interface other than IRB, and the traffic corresponds to a Layer 3 (*,G) state, the L3 Gateway can create (S,G) state. The IIF will be set to the external interface over which the traffic is expected. The OIF list will contain the SBD IRB interface, as well as the IRB interfaces of any other BDs attached to the PEG DR that have locally attached receivers with interest in the (S,G) traffic. The (S,G) state will ensure that the external traffic is sent down the SBD IRB interface. The following text will assume this procedure; however, other implementation techniques may also be possible.
これを処理する1つの方法は、次のとおりです。L3ゲートウェイがIRB以外のインターフェイスからのトラフィック（s、g）を受信し、トラフィックがレイヤー3（*、g）状態に対応する場合、L3ゲートウェイは（s、g）状態を作成できます。IIFは、トラフィックが予想される外部インターフェイスに設定されます。OIFリストには、SBD IRBインターフェイスと、（s、g）トラフィックに関心があるローカルに添付されているPEG DRに接続された他のBDのIRBインターフェイスが含まれます。（s、g）状態は、外部トラフィックがSBD IRBインターフェイスに送られることを保証します。次のテキストでは、この手順を想定しています。ただし、他の実装手法も可能です。
If a particular BD is attached to several L3 Gateways, one of the L3 Gateways becomes the DR for that BD (see Section 6.1.2.4). If the interworking scenario requires FHR functionality, it is generally the DR for a particular BD that is responsible for performing that functionality on behalf of the source hosts on that BD (e.g., if the interworking scenario requires that PIM Register messages be sent by an FHR, the DR for a given BD would send the PIM Register messages for sources on that BD). Although, note that the DR for the SBD does not perform FHR functionality on behalf of external sources.
特定のBDがいくつかのL3ゲートウェイに接続されている場合、L3ゲートウェイの1つがそのBDのDRになります（セクション6.1.2.4を参照）。インターワーキングシナリオにFHR機能が必要な場合、一般に、そのBDのソースホストに代わってその機能を実行するのは特定のBDのDRです（たとえば、インターワーキングシナリオでPIMレジスタメッセージをFHRによって送信することを要求する場合、特定のBDのDRは、そのBDのソースのPIMレジスタメッセージを送信します）。ただし、SBDのDRは、外部ソースに代わってFHR機能を実行しないことに注意してください。
An optional alternative is to have each L3 Gateway perform FHR functionality for locally attached sources. Then, the DR would only have to perform FHR functionality on behalf of sources that are locally attached to itself AND sources that are not attached to any L3 Gateway.
オプションの代替案は、各L3ゲートウェイにローカルに添付されたソースに対してFHR機能を実行させることです。その後、DRは、局所的にそれ自体に添付されているソースと、L3ゲートウェイに添付されていないソースに代わってFHR機能を実行する必要があります。
Note that if it is possible that more than one BD contains a tenant multicast router, then a PE receiving a SMET route for that BD MUST NOT reconstruct IGMP/MLD Join Reports from the SMET route and MUST NOT transmit any such IGMP/MLD Join Reports on its local ACs attaching to that BD. Otherwise, multicast traffic may be duplicated.
複数のBDにテナントマルチキャストルーターが含まれている可能性がある場合、そのBDのSMETルートを受信するPEは、IGMP/MLDのReportを再構築してはならず、そのようなIGMP/MLDのMLD参加レポートを送信してはなりません。そのBDに付着するローカルACS。それ以外の場合、マルチキャストトラフィックが複製される場合があります。
In this section, we specify the procedures necessary to allow EVPN PEs running OISM procedures to interwork with L3VPN PEs that run BGP-based MVPN [RFC6514] procedures. More specifically, the procedures herein allow a given EVPN Tenant Domain to become part of an L3VPN/ MVPN and support multicast flows where either of the following occurs:
このセクションでは、BGPベースのMVPN [RFC6514]手順を実行するL3VPN PESとの相互作業を実行するEVPN PESを実行するEVPN PESを許可するために必要な手順を指定します。より具体的には、ここでの手順により、特定のEVPNテナントドメインがL3VPN/ MVPNの一部になり、次のいずれかが発生するマルチキャストフローをサポートすることができます。
* The source of a given multicast flow is attached to an Ethernet segment whose BD is part of an EVPN Tenant Domain, and one or more receivers of the flow are attached to the network via L3VPN/MVPN. (Other receivers may be attached to the network via EVPN.)
* 特定のマルチキャストフローのソースは、BDがEVPNテナントドメインの一部であるイーサネットセグメントに接続され、フローの1つ以上の受信機がL3VPN/MVPNを介してネットワークに接続されます。（EVPNを介して他のレシーバーがネットワークに接続される場合があります。）
* The source of a given multicast flow is attached to the network via L3VPN/MVPN, and one or more receivers of the flow are attached to an Ethernet segment that is part of an EVPN Tenant Domain. (Other receivers may be attached via L3VPN/MVPN.)
* 特定のマルチキャストフローのソースは、L3VPN/MVPNを介してネットワークに接続され、フローの1つ以上の受信機がEVPNテナントドメインの一部であるイーサネットセグメントに接続されます。（他のレシーバーは、L3VPN/MVPNを介して接続できます。）
In this interworking model, existing L3VPN/MVPN PEs are unaware that certain sources or receivers are part of an EVPN Tenant Domain. The existing L3VPN/MVPN nodes run only their standard procedures and are entirely unaware of EVPN. Interworking is achieved by having some or all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN procedures, as detailed in the following subsections.
このインターワーキングモデルでは、既存のL3VPN/MVPN PESは、特定のソースまたは受信機がEVPNテナントドメインの一部であることを認識していません。既存のL3VPN/MVPNノードは、標準手順のみを実行し、EVPNを完全に認識していません。インターワーキングは、以下のサブセクションで詳述されているように、L3VPN/MVPN手順を実行するL3ゲートウェイとしてEVPN PES機能の一部またはすべてを使用することで達成されます。
In this section, we assume that there are no tenant multicast routers on any of the EVPN-attached Ethernet segments. (Of course, there may be multicast routers in the L3VPN.) Consideration of the case where there are tenant multicast routers is addressed in Section 7.
このセクションでは、EVPNで取り付けられたイーサネットセグメントのいずれにもテナントマルチキャストルーターがないと仮定します。（もちろん、L3VPNにはマルチキャストルーターがある場合があります。）テナントマルチキャストルーターがある場合の考慮事項は、セクション7で対処されています。
To support MVPN/EVPN interworking, we introduce the notion of an MVPN/EVPN Gateway (MEG).
MVPN/EVPNインターワーキングをサポートするために、MVPN/EVPNゲートウェイ（MEG）の概念を紹介します。
A MEG is an L3 Gateway (see Section 6.1.1); hence, it is both an OISM PE and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it will have an IP-VRF. If the Tenant Domain is part of an L3VPN/MVPN, the IP-VRF also serves as an L3VPN VRF [RFC4364]. The IRB interfaces of the IP-VRF are considered to be VRF interfaces of the L3VPN VRF. The L3VPN VRF may also have other local VRF interfaces that are not EVPN IRB interfaces.
MEGはL3ゲートウェイです（セクション6.1.1を参照）。したがって、それはOism PEとL3VPN/MVPN PEの両方です。特定のEVPNテナントドメインの場合、IP-VRFがあります。テナントドメインがL3VPN/MVPNの一部である場合、IP-VRFはL3VPN VRF [RFC4364]としても機能します。IP-VRFのIRBインターフェイスは、L3VPN VRFのVRFインターフェイスと見なされます。L3VPN VRFには、EVPN IRBインターフェイスではない他のローカルVRFインターフェイスもあります。
The VRF on the MEG will import VPN-IP routes [RFC4364] from other L3VPN PE routers. It will also export VPN-IP routes to other L3VPN PE routers. In order to do so, it must be appropriately configured with the RTs used in the L3VPN to control the distribution of the VPN-IP routes. In general, these RTs will be different than the RTs used for controlling the distribution of EVPN routes, as there is no need to distribute EVPN routes to L3VPN-only PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs.
MEGのVRFは、他のL3VPN PEルーターからVPN-IPルート[RFC4364]をインポートします。また、VPN-IPルートを他のL3VPN PEルーターにエクスポートします。そのためには、VPN-IPルートの分布を制御するためにL3VPNで使用されるRTSで適切に構成する必要があります。一般に、これらのRTは、EVPNルートの分布を制御するために使用されるRTとは異なります。これは、EVPNルートをL3VPNのみのPESに分布させる必要がなく、L3VPN/MVPNルートをEVPNのみのPESに分布させる理由はありません。
Note that the RDs in the imported VPN-IP routes will not necessarily conform to the EVPN rules (as specified in [RFC7432]) for creating RDs. Therefore, a MEG MUST NOT expect the RDs of the VPN-IP routes to be of any particular format other than what is required by the L3VPN/MVPN specifications.
輸入されたVPN-IPルートのRDSは、RDSを作成するために必ずしもEVPNルール（[RFC7432]で指定されている）に適合しないことに注意してください。したがって、MEGは、VPN-IPルートのRDSが、L3VPN/MVPN仕様で必要なもの以外の特定の形式であることを期待してはなりません。
The VPN-IP routes that a MEG exports to L3VPN are subnet routes and/ or host routes for the multicast sources that are part of the EVPN Tenant Domain. The exact set of routes that need to be exported is discussed in Section 6.1.2.2.
MEGがL3VPNにエクスポートするVPN-IPルートは、EVPNテナントドメインの一部であるマルチキャストソースのサブネットルートおよび/またはホストルートです。エクスポートする必要があるルートの正確なセットについては、セクション6.1.2.2で説明します。
Each IMET route originated by a MEG SHOULD carry a Multicast Flags Extended Community with the MEG flag set, indicating that the originator of the IMET route is a MEG. However, PE1 will consider PE2 to be a MEG if PE1 imports at least one IMET route from PE2 that carries the Multicast Flags EC with the MEG flag set.
MEGが起源とする各IMETルートは、MEGフラグセットを備えたマルチキャストフラグ拡張コミュニティを搭載する必要があります。これは、IMETルートのオリジネーターがMEGであることを示しています。ただし、PE1がMEGフラグセットを備えたマルチキャストフラグECを運ぶPE2から少なくとも1つのIMETルートをインポートする場合、PE1はPE2をMEGと見なします。
All the MEGs of a given Tenant Domain attach to the SBD of that domain, and one of them is selected to be the SBD's Designated Router (the MEG SBD-DR) for the domain. The selection procedure is discussed in Section 6.1.2.4.
特定のテナントドメインのすべてのメグは、そのドメインのSBDに付着し、そのうちの1つはドメインのSBDの指定ルーター（MEG SBD-DR）に選択されます。選択手順については、セクション6.1.2.4で説明します。
In this model of operation, MVPN procedures and EVPN procedures are largely independent. In particular, there is no assumption that MVPN and EVPN use the same kind of tunnels. Thus, no special procedures are needed to handle the common scenarios where, e.g., EVPN uses VXLAN tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses IR but MVPN uses MPLS P2MP tunnels.
この動作モデルでは、MVPN手順とEVPN手順はほとんど独立しています。特に、MVPNとEVPNが同じ種類のトンネルを使用するという仮定はありません。したがって、たとえばEVPNがVXLANトンネルを使用するが、MVPNがMPLS P2MPトンネルを使用する、またはEVPNがIRを使用しますが、MVPNがMPLS P2MPトンネルを使用する一般的なシナリオを処理するために特別な手順は必要ありません。
Similarly, no special procedures are needed to prevent duplicate data delivery on Ethernet segments that are multihomed.
同様に、マルチホームのイーサネットセグメントでのデータ配信の重複を防ぐために特別な手順は必要ありません。
The MEG does have some special procedures (described below) for interworking between EVPN and MVPN; these have to do with selection of the Upstream PE for a given multicast source, with the exporting of VPN-IP routes and with the generation of MVPN C-multicast routes triggered by the installation of SMET routes.
MEGには、EVPNとMVPN間のインターワーキングのためのいくつかの特別な手順（以下で説明）があります。これらは、特定のマルチキャストソースの上流のPEの選択、VPN-IPルートのエクスポート、およびSMETルートの設置によって引き起こされるMVPN Cマルチキャストルートの生成に関係しています。
Consider a multicast source S. It is possible that a MEG will import both an EVPN unicast route to S and a VPN-IP route (or an ordinary IP route), where the prefix length of each route is the same. In order to draw (S,G) multicast traffic for any group G, the MEG SHOULD use the EVPN route rather than the VPN-IP or IP route to determine the Upstream PE (see Section 5 of [RFC6513]).
マルチキャストのソースSを考えてみましょう。MEGは、各ルートのプレフィックス長が同じであるEVPNユニキャストルートとVPN-IPルート（または通常のIPルート）の両方をインポートする可能性があります。グループGの（S、G）マルチキャストトラフィックを描画するには、MEGはVPN-IPまたはIPルートではなくEVPNルートを使用して上流のPEを決定する必要があります（[RFC6513]のセクション5を参照）。
Doing so ensures that when an EVPN tenant system desires to receive a multicast flow from another EVPN tenant system, the traffic from the source to that receiver stays within the EVPN domain. This prevents problems that might arise if there is a unicast route via L3VPN to S but no multicast routers along the routed path. This also prevents problem that might arise as a result of the fact that the MEGs will import each others' VPN-IP routes.
そうすることで、EVPNテナントシステムが別のEVPNテナントシステムからマルチキャストフローを受信したい場合、ソースからそのレシーバーへのトラフィックがEVPNドメイン内に留まることが保証されます。これにより、L3VPNを介してSにユニキャストルートがあるが、ルーティングされたパスに沿ってマルチキャストルーターがない場合に発生する可能性のある問題が防止されます。これはまた、MEGSがお互いのVPN-IPルートをインポートするという事実の結果として発生する可能性のある問題を防ぎます。
In Section 6.1.2.1.2, we describe the procedures to be used when the selected route to S is a VPN-IP route.
セクション6.1.2.1.2では、Sへの選択されたルートがVPN-IPルートである場合に使用する手順について説明します。
Consider a tenant system, say R, on a particular BD, say BD-R. Suppose R wants to receive (S,G) multicast traffic, where source S is not attached to any PE in the EVPN Tenant Domain but is attached to an MVPN PE.
特定のBDのテナントシステム、たとえばrをBD-Rと考えてください。Rが（S、G）マルチキャストトラフィックを受信したいと仮定します。ここでは、ソースSがEVPNテナントドメインのPEに接続されていないが、MVPN PEに接続されています。
* Suppose R is on a singly homed Ethernet segment of BD-R and that segment is attached to PE1, where PE1 is a MEG. PE1 learns via IGMP/MLD listening that R is interested in (S,G). PE1 determines from its VRF that there is no route to S within the Tenant Domain (i.e., no EVPN RT-2 route matching on S's IP address) but that there is a route to S via L3VPN (i.e., the VRF contains a subnet or host route to S that was received as a VPN-IP route). Thus, PE1 originates (if it hasn't already) an MVPN C-multicast Source Tree Join (S,G) route. The route is constructed according to normal MVPN procedures.
* rがBD-Rの単独で故郷のイーサネットセグメントにあり、そのセグメントがPE1に接続されているとします。ここで、PE1はMEGです。PE1は、IGMP/MLDを介して、Rが（S、G）に関心があることを聞いています。PE1は、そのVRFから、テナントドメイン内にSへのルートがないこと（つまり、SのIPアドレスに一致するEVPN RT-2ルートはありません）が、L3VPNを介してSへのルートがあることを決定します（つまり、VRFにはサブネットまたはサブネットまたは含まれています。VPN-IPルートとして受信されたSへのホストルート）。したがって、PE1は（まだ持っていない場合）MVPN C-Multicast Source Tree Join（S、G）ルートを発信します。ルートは、通常のMVPN手順に従って構築されます。
The Layer 2 multicast state is constructed as specified in Section 4.1.
レイヤー2マルチキャスト状態は、セクション4.1で指定されているように構築されています。
In the Layer 3 multicast state, the IIF is the appropriate MVPN tunnel, and the IRB interface to BD-R is added to the OIF list.
レイヤー3マルチキャスト状態では、IIFが適切なMVPNトンネルであり、BD-RへのIRBインターフェイスがOIFリストに追加されます。
When PE1 receives (S,G) traffic from the appropriate MVPN tunnel, it performs IP processing of the traffic and then sends the traffic down its IRB interface to BD-R. Following normal OISM procedures, the (S,G) traffic will be encapsulated for Ethernet and sent on the AC to which R is attached.
PE1が適切なMVPNトンネルから（S、G）トラフィックを受信すると、トラフィックのIP処理を実行し、IRBインターフェイスをBD-Rに送信します。通常のOISM手順に続いて、（s、g）トラフィックはイーサネットのカプセル化され、rが接続されているACに送信されます。
* Suppose R is on a singly homed Ethernet segment of BD-R and that segment is attached to PE1, where PE1 is an OISM PE but is NOT a MEG. PE1 learns via IGMP/MLD listening that R is interested in (S,G). PE1 follows normal OISM procedures, originating an SBD-SMET route for (S,G); this route will be received by all the MEGs of the Tenant Domain, including the MEG SBD-DR. From PE1's IMET routes, the MEG SBD-DR can determine whether or not PE1 is itself a MEG. If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't already) an MVPN C-multicast Source Tree Join (S,G) route. This will cause the MEG SBD-DR to receive (S,G) traffic on an MVPN tunnel.
* RがBD-Rの単独でホームされたイーサネットセグメントにあり、そのセグメントがPE1に接続されているとします。ここで、PE1はOISM PEであるが、MEGではありません。PE1は、IGMP/MLDを介して、Rが（S、G）に関心があることを聞いています。PE1は通常のOISM手順に従い、（S、G）のSBDスメスルートを発信します。このルートは、MEG SBD-DRを含むテナントドメインのすべてのメグによって受信されます。PE1のIMETルートから、MEG SBD-DRはPE1自体がMEGであるかどうかを判断できます。PE1がMEGでない場合、MEG SBD-DRは（まだ持っていない場合）MVPN C-Multicastソースツリー（S、G）ルートを発信します。これにより、MEG SBD-DRはMVPNトンネルの（S、G）トラフィックを受信します。
The Layer 2 multicast state is constructed as specified in Section 4.1.
レイヤー2マルチキャスト状態は、セクション4.1で指定されているように構築されています。
In the Layer 3 multicast state, the IIF is the appropriate MVPN tunnel, and the IRB interface to the SBD is added to the OIF list.
レイヤー3マルチキャスト状態では、IIFが適切なMVPNトンネルであり、SBDへのIRBインターフェイスがOIFリストに追加されます。
When the MEG SBD-DR receives (S,G) traffic on an MVPN tunnel, it performs IP processing of the traffic and then sends the traffic down its IRB interface to the SBD. Following normal OISM procedures, the traffic will be encapsulated for Ethernet and delivered to all PEs in the Tenant Domain that have interest in (S,G), including PE1.
MEG SBD-DRがMVPNトンネルのトラフィック（S、G）を受信すると、トラフィックのIP処理を実行し、IRBインターフェイスをSBDに送信します。通常のOISM手順に続いて、トラフィックはイーサネットのカプセル化され、PE1を含む（s、g）に関心のあるテナントドメインのすべてのPEに配信されます。
* If R is on a multihomed Ethernet segment of BD-R, one of the PEs attached to the segment will be its DF (following normal EVPN procedures), and the DF will know (via IGMP/MLD listening or the procedures of [RFC9251]) that a tenant system reachable via one of its local ACs to BD-R is interested in (S,G) traffic. The DF is responsible for originating an SBD-SMET route for (S,G), following normal OISM procedures. If the DF is a MEG, it MUST originate the corresponding MVPN C-multicast Source Tree Join (S,G) route; if the DF is not a MEG, the MEG SBD-DR SBD MUST originate the C-multicast route when it receives the SMET route.
* rがBD-Rのマルチホームイーサネットセグメントにある場合、セグメントに接続されたPEの1つがDF（通常のEVPN手順に続いて）であり、DFは（IGMP/MLDリスニングまたは[RFC9251]の手順を介して知っています。）ローカルACSからBD-Rの1つを介して到達可能なテナントシステムが（S、G）トラフィックに関心があること。DFは、通常のOISM手順に従って、（s、g）のSBDスメスルートを発信する責任があります。DFがMEGの場合、対応するMVPN C-Multicast Source Tree Join（S、G）ルートを発信する必要があります。DFがMEGでない場合、MEG SBD-DR SBDは、SMETルートを受信するときにCマルチキャストルートを発信する必要があります。
Optionally, if the non-DF is a MEG, it MAY originate the corresponding MVPN C-multicast Source Tree Join (S,G) route. This will cause the traffic to flow to both the DF and the non-DF, but only the DF will forward the traffic out an AC. This allows for quicker recovery if the DF's local AC to R fails.
オプションで、非DFがMEGの場合、対応するMVPN Cマルチカストソースツリー（S、G）ルートを発生する可能性があります。これにより、トラフィックはDFと非DFの両方に流れますが、DFのみがトラフィックをACから転送します。これにより、DFのローカルACからRが失敗した場合、迅速に回復できます。
* If R is attached to a non-OISM PE, it will receive the traffic via an IPMG, as specified in Section 5.
* rが非オイズムPEに接続されている場合、セクション5で指定されているように、IPMGを介してトラフィックを受け取ります。
If an EVPN-attached receiver is interested in (*,G) traffic, and if it is possible for there to be sources of (*,G) traffic that are attached only to L3VPN nodes, the MEGs will have to know the group-to-RP mappings. That will enable them to originate MVPN C-multicast Shared Tree Join (*,G) routes and to send them toward the RP. (Since we are assuming in this section that there are no tenant multicast routers attached to the EVPN Tenant Domain, the RP must be attached via L3VPN. Alternatively, the MEG itself could be configured to function as an RP for group G.)
EVPNで攻撃されたレシーバーが（*、g）トラフィックに関心があり、L3VPNノードにのみ接続されている（*、g）トラフィックのソースがある場合、MEGSはグループを知る必要があります。To-RPマッピング。これにより、MVPN C-Multicastの共有ツリー結合（*、G）ルートを発信し、RPに送信できます。（このセクションでは、EVPNテナントドメインに取り付けられたテナントマルチキャストルーターがないと仮定しているため、RPはL3VPNを介して接続する必要があります。あるいは、MEG自体をグループGのRPとして機能するように構成できます。）
The Layer 2 multicast states are constructed as specified in Section 4.1.
レイヤー2マルチキャスト状態は、セクション4.1で指定されているように構築されています。
In the Layer 3 (*,G) multicast state, the IIF is the appropriate MVPN tunnel. A MEG will add its IRB interfaces to the (*,G) OIF list for any BDs containing locally attached receivers. If there are receivers attached to other EVPN PEs, then whenever (S,G) traffic from an external source matches a (*,G) state, the MEG will create (S,G) state, with the MVPN tunnel as the IIF, the OIF list copied from the (*,G) state, and the SBD IRB interface added to the OIF list. (Please see the discussion in Section 6.1.1 regarding the inclusion of the SBD IRB interface in a (*,G) state; the SBD IRB interface is only used in the OIF list for traffic from external sources.)
レイヤー3（*、g）マルチキャスト状態では、IIFは適切なMVPNトンネルです。MEGは、ローカルに接続されたレシーバーを含むBDの（*、g）OIFリストにIRBインターフェイスを追加します。他のEVPN PEに接続されたレシーバーがある場合、外部ソースからのトラフィックが（*、g）状態に一致する場合、MEGは（s、g）状態を作成し、MVPNトンネルをiifとして作成します。（*、g）状態からコピーされたOIFリストとSBD IRBインターフェイスがOIFリストに追加されました。（（*、g）状態にSBD IRBインターフェイスを含めることに関するセクション6.1.1の説明を参照してください。SBDIRBインターフェイスは、外部ソースからのトラフィックのためにOIFリストでのみ使用されます。）
Normal MVPN procedures will then result in the MEG getting the (*,G) traffic from all the multicast sources for G that are attached via L3VPN. This traffic arrives on MVPN tunnels. When the MEG removes the traffic from these tunnels, it does the IP processing. If there are any receivers on a given BD, say BD-R, that are attached via local EVPN ACs, the MEG sends the traffic down its BD-R IRB interface. If there are any other EVPN PEs that are interested in the (*,G) traffic, the MEG sends the traffic down the SBD IRB interface. Normal OISM procedures then distribute the traffic as needed to other EVPN PEs.
次に、通常のMVPN手順により、MEGがL3VPNを介して接続されているGのすべてのマルチキャストソースから（*、g）トラフィックを取得します。このトラフィックは、MVPNトンネルに到着します。MEGがこれらのトンネルからトラフィックを削除すると、IP処理が行われます。特定のBD（BD-RなどのレシーバーがローカルEVPN ACSを介して接続されている場合、MEGはBD-R IRBインターフェイスにトラフィックを送信します。（*、g）トラフィックに関心のある他のEVPN PEがある場合、MEGはSBD IRBインターフェイスにトラフィックを送信します。次に、通常のOISM手順は、必要に応じて他のEVPN PESにトラフィックを配布します。
Consider the case where an EVPN tenant system S is sending IP multicast traffic to group G and there is a receiver R for the (S,G) traffic that is attached to the L3VPN but not attached to the EVPN Tenant Domain. (In this document, we assume that the L3VPN-/MVPN-only nodes will not have any special procedures to deal with the case where a source is inside an EVPN domain.)
EVPNテナントシステムSがIPマルチキャストトラフィックをグループGに送信し、L3VPNに取り付けられているがEVPNテナントドメインに添付されていない（S、G）トラフィックのレシーバーRがある場合を考えてみましょう。（このドキュメントでは、L3VPN-/MVPNのみのノードには、ソースがEVPNドメイン内にある場合に対処するための特別な手順がないと仮定します。）
In this case, an L3VPN PE through which R can be reached has to send an MVPN C-multicast Join (S,G) route to one of the MEGs that is attached to the EVPN Tenant Domain. For this to happen, the L3VPN PE must have imported a VPN-IP route for S (either a host route or a subnet route) from a MEG.
この場合、Rに到達できるL3VPN PEは、EVPNテナントドメインに接続されているMEGSの1つにMVPN C-Multicast結合（S、G）ルートを送信する必要があります。これを行うには、L3VPN PEは、MEGからS（ホストルートまたはサブネットルート）用のVPN-IPルートをインポートしている必要があります。
If a MEG determines that there is multicast source transmitting on one of its ACs, the MEG SHOULD originate a VPN-IP host route for that source. This determination SHOULD be made by examining the IP multicast traffic that arrives on the ACs. (It MAY be made by provisioning.) A MEG SHOULD NOT export a VPN-IP host route for any IP address that is not known to be a multicast source (unless it has some other reason for exporting such a route). The VPN-IP host route for a given multicast source MUST be withdrawn if the source goes silent for a configurable period of time or if it can be determined that the source is no longer reachable via a local AC.
MEGがマルチキャストソースがACSの1つに送信されていると判断した場合、MEGはそのソースのVPN-IPホストルートを発信する必要があります。この決定は、ACSに到着するIPマルチキャストトラフィックを調べることで行う必要があります。（プロビジョニングによって作成される場合があります。）MEGは、マルチキャストソースであると知られていないIPアドレスのVPN-IPホストルートをエクスポートしないでください（このようなルートをエクスポートする他の理由がない限り）。特定のマルチキャストソースのVPN-IPホストルートは、ソースが構成可能な期間沈黙している場合、またはソースがローカルACを介してもはや到達できなくなったと判断できる場合、撤回する必要があります。
A MEG SHOULD also originate a VPN-IP subnet route for each of the BDs in the Tenant Domain.
MEGは、テナントドメイン内の各BDSのVPN-IPサブネットルートも発生する必要があります。
VPN-IP routes exported by a MEG must carry any attributes or Extended Communities that are required by L3VPN and MVPN. In particular, a VPN-IP route exported by a MEG must carry a VRF Route Import Extended Community corresponding to the IP-VRF from which it is imported and a Source AS Extended Community.
MEGによってエクスポートされるVPN-IPルートは、L3VPNおよびMVPNで必要とされる属性または拡張コミュニティを運ぶ必要があります。特に、MEGによってエクスポートされるVPN-IPルートは、IP-VRFに対応するVRFルートインポート拡張コミュニティと、拡張コミュニティとしてソースを搭載する必要があります。
As a result, if S is attached to a MEG, the L3VPN nodes will direct their MVPN C-multicast Join routes to that MEG. Normal MVPN procedures will cause the traffic to be delivered to the L3VPN nodes. The Layer 3 multicast state for (S,G) will have the MVPN tunnel on its OIF list. The IIF will be the IRB interface leading to the BD containing S.
その結果、SがMEGに接続されている場合、L3VPNノードはMVPN C-Multicast結合ルートをそのMEGに向けます。通常のMVPN手順により、トラフィックがL3VPNノードに配信されます。（S、G）のレイヤー3マルチキャスト状態には、OIFリストにMVPNトンネルがあります。IIFは、Sを含むBDにつながるIRBインターフェイスになります
If S is not attached to a MEG, the L3VPN nodes will direct their C-multicast Join routes to whichever MEG appears to be on the best route to S's subnet. Upon receiving the C-multicast Join, that MEG will originate an EVPN SMET route for (S,G). As a result, the MEG will receive the (S,G) traffic at Layer 2 via the OISM procedures. The (S,G) traffic will be sent up the appropriate IRB interface, and the Layer 3 MVPN procedures will ensure that the traffic is delivered to the L3VPN nodes that have requested it. The Layer 3 multicast state for (S,G) will have the MVPN tunnel in the OIF list, and the IIF will be one of the following:
SがMEGに接続されていない場合、L3VPNノードは、Sのサブネットへの最良のルートにあると思われるMEGにC-Multicast結合ルートを導きます。C-Multicast結合を受信すると、そのMEGは（S、G）のEVPN SMETルートを発信します。その結果、MEGはOISM手順を介してレイヤー2で（s、g）トラフィックを受け取ります。（s、g）トラフィックは適切なIRBインターフェイスに送信され、レイヤー3 mVPN手順により、トラフィックが要求されたL3VPNノードに配信されるようになります。（s、g）のレイヤー3マルチキャスト状態には、OIFリストにMVPNトンネルがあり、IIFは次のいずれかになります。
* If S belongs to a BD that is attached to the MEG, the IIF will be the IRB interface to that BD.
* SがMEGに接続されているBDに属している場合、IIFはそのBDのIRBインターフェイスになります。
* Otherwise, the IIF will be the SBD IRB interface.
* それ以外の場合、IIFはSBD IRBインターフェイスになります。
Note that this works even if S is attached to a non-OISM PE, per the procedures of Section 5.
セクション5の手順に従って、Sが非オイズムPEに接続されている場合でも、これは機能することに注意してください。
Suppose the MEG SBD-DR learns that one of the PEs in its Tenant Domain is interested in (*,G) traffic, where G is an ASM group. If there are no tenant multicast routers, the MEG SBD-DR SHOULD perform the First Hop Router (FHR) functionality for group G on behalf of the Tenant Domain, as described in [RFC7761]. This means that the MEG SBD-DR must know the identity of the RP for each group, must send Register messages to the RP, etc.
MEG SBD-DRが、テナントドメインのPEの1つが（*、G）トラフィックに関心があることを知ったとします。ここで、GはASMグループです。テナントマルチキャストルーターがない場合、MEG SBD-DRは、[RFC7761]で説明されているように、テナントドメインに代わってグループGの最初のホップルーター（FHR）機能を実行する必要があります。これは、MEG SBD-DRが各グループのRPのIDを知る必要があることを意味し、RPなどにレジスタメッセージを送信する必要があります。
If the MEG SBD-DR is to be the FHR for the Tenant Domain, it must see all the multicast traffic that is sourced from within the domain and destined to an ASM group address. The MEG can ensure this by originating an SBD-SMET route for (*,*).
MEG SBD-DRがテナントドメインのFHRである場合、ドメイン内から供給され、ASMグループアドレスに運命づけられているすべてのマルチキャストトラフィックを確認する必要があります。MEGは、（*、*）のSBDスメットルートを発信することにより、これを確実にすることができます。
(As a possible optimization, an SBD-SMET route for (*, any ASM group) may be defined in a separate document.)
（最適化の可能性として、（*、ASMグループ）のSBD-Smetルートは、別のドキュメントで定義される場合があります。）
In some deployment scenarios, it may be preferred that the MEG that receives the (S,G) traffic over an AC be the one providing the FHR functionality. This behavior is OPTIONAL. If this option is used, it MUST be ensured that the MEG DR does not provide the FHR functionality for (S,G) traffic that is attached to another MEG; FHR functionality for (S,G) traffic from a particular source S MUST be provided by only a single router.
いくつかの展開シナリオでは、ACの（s、g）トラフィックを受信するMEGがFHR機能を提供するものであることが推奨される場合があります。この動作はオプションです。このオプションを使用する場合、MEG DRが別のMEGに接続されている（S、G）トラフィックのFHR機能を提供しないことを確認する必要があります。特定のソースSからのトラフィックのFHR機能は、単一のルーターのみで提供する必要があります。
Other deployment scenarios are also possible. For example, one might want to configure the MEGs themselves to be RPs. In this case, the RPs would have to exchange with each other information about which sources are active. The method exchanging such information is outside the scope of this document.
他の展開シナリオも可能です。たとえば、MEG自体をRPSに設定したい場合があります。この場合、RPSは、どのソースがアクティブであるかについての情報を互いに交換する必要があります。そのような情報を交換する方法は、このドキュメントの範囲外です。
Suppose S is attached to a segment that is all-active multihomed to PE1 and PE2. If S is transmitting to two groups, say G1 and G2, it is possible that PE1 will receive the (S,G1) traffic from S, whereas PE2 will receive the (S,G2) traffic from S.
Sが、PE1およびPE2にすべてのマルチホームされたセグメントに接続されていると仮定します。Sが2つのグループ、たとえばG1とG2に送信している場合、PE1はSから（S、G1）トラフィックを受け取るのに対し、PE2はSから（S、G2）トラフィックを受け取る可能性があります。
This creates an issue for MVPN/EVPN interworking, because there is no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE for (S,G1) traffic while selecting PE2 as the ingress PE for (S,G2) traffic.
これにより、MVPN/EVPNインターワーキングの問題が作成されます。これは、L3VPN/MVPNノードに（S、G1）トラフィックのイングレスPEとしてPE1を選択すると、（S、G2）トラフィックのイングレスPEとしてPE2を選択する方法がないためです。
However, the following procedure ensures that the IP multicast traffic will still flow, even if the L3VPN/MVPN nodes pick the wrong EVPN PE as the Upstream PE for, e.g., the (S,G1) traffic.
ただし、L3VPN/MVPNノードが間違ったEVPN PEを上流のPEとして選択する場合でも、次の手順により、IPマルチキャストトラフィックが依然として流れることが保証されます。
Suppose S is on an Ethernet segment, belonging to BD1, that is multihomed to both PE1 and PE2, where PE1 is a MEG. And suppose that IP multicast traffic from S to G travels over the AC that attaches the segment to PE2. If PE1 receives a C-multicast Source Tree Join (S,G) route, it MUST originate a SMET route for (S,G). Normal OISM procedures will then cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will also cause PE1 to send the (S,G) traffic up its BD1 IRB interface. Normal MVPN procedures will then cause PE1 to forward the traffic on an MVPN tunnel. In this case, the routing is not optimal, but the traffic does flow correctly.
SがBD1に属するイーサネットセグメントにあると仮定します。これは、PE1とPE2の両方にマルチホームされており、PE1はMEGです。また、SからGへのIPマルチキャストトラフィックが、セグメントをPE2に接続するACを越えて移動すると仮定します。PE1がC-Multicast Source Tree（S、G）ルートを受信する場合、（S、G）のSMETルートを発生する必要があります。通常のOISM手順により、PE2はEVPN IPマルチキャストトンネルで（s、g）トラフィックをPE1に送信します。また、通常のOISM手順により、PE1はBD1 IRBインターフェイスに（s、g）トラフィックを送信します。通常のMVPN手順により、PE1はMVPNトンネルでトラフィックを転送します。この場合、ルーティングは最適ではありませんが、トラフィックは正しく流れます。
The routing of IP multicast traffic between MVPN nodes and EVPN nodes will be optimal as long as there is a MEG along the optimal route. There are various deployment strategies that can be used to obtain optimal routing between MVPN and EVPN.
MVPNノードとEVPNノード間のIPマルチキャストトラフィックのルーティングは、最適なルートに沿ってMEGがある限り、最適です。MVPNとEVPNの間で最適なルーティングを取得するために使用できるさまざまな展開戦略があります。
In one such scenario, a Tenant Domain will have a small number of strategically placed MEGs. For example, a data center may have a small number of MEGs that connect it to a wide-area network. Then, the optimal route into or out of the data center would be through the MEGs.
そのようなシナリオの1つでは、テナントドメインには戦略的に配置されたメグが少なくなります。たとえば、データセンターには、幅広いネットワークに接続する少数のメグがある場合があります。次に、データセンターへのまたは外出する最適なルートは、MEGSを介して行われます。
In this scenario, the MEGs do not need to originate VPN-IP host routes for the multicast sources; they only need to originate VPN-IP subnet routes. The internal structure of the EVPN is completely hidden from the MVPN node. EVPN actions, such as MAC Mobility and Mass Withdrawal [RFC7432], have zero impact on the MVPN control plane.
このシナリオでは、MEGSはマルチキャストソースのVPN-IPホストルートを発信する必要はありません。VPN-IPサブネットルートを発信するだけです。EVPNの内部構造は、MVPNノードから完全に隠されています。MACモビリティや大量離脱[RFC7432]などのEVPNアクションは、MVPNコントロールプレーンにゼロの影響を与えます。
While this deployment scenario provides the most optimal routing and has the least impact on the installed based of MVPN nodes, it does complicate network planning considerations.
この展開シナリオは、最も最適なルーティングを提供し、MVPNノードのインストールされているインストールに影響が最も少ないが、ネットワーク計画の考慮事項を複雑にします。
Another way of providing routing that is close to optimal is to turn each EVPN PE into a MEG. Then, routing of MVPN-to-EVPN traffic is optimal. However, routing of EVPN-to-MVPN traffic is not guaranteed to be optimal when a source host is on a multihomed Ethernet segment (as discussed in Section 6.1.2.2.)
最適に近いルーティングを提供する別の方法は、各EVPN PEをMEGに変えることです。次に、MVPNからEVPNへのトラフィックのルーティングが最適です。ただし、Sourceホストがマルチホームのイーサネットセグメントにある場合、EVPNからMVPNへのトラフィックのルーティングは最適ではないことは保証されていません（セクション6.1.2.2で説明しています。）
The obvious disadvantage of this method is that it requires every EVPN PE to be a MEG.
この方法の明らかな欠点は、すべてのEVPN PEがMEGであることを必要とすることです。
The procedures specified in this document allow an operator to add MEG functionality to any subset of its EVPN OISM PEs. This allows an operator to make whatever trade-offs deemed appropriate between optimal routing and MEG deployment.
このドキュメントで指定された手順により、オペレーターはEVPN OISM PESの任意のサブセットにMEG機能を追加できます。これにより、オペレーターは、最適なルーティングとMEG展開の間で適切とみなされるトレードオフを行うことができます。
Every PE that is eligible for selection as the MEG SBD-DR originates an SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry a Multicast Flags EC with the MEG flag set.
MEG SBD-DRがSBD-IMETルートを発生するため、選択の対象となるすべてのPE。セクション5で述べたように、これらのSBD-IMETルートには、MEGフラグがセットされたマルチキャストフラグECがあります。
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF Election EC and its use are specified in [RFC8584]. When the route is originated, the AC-DF bit in the DF Election EC SHOULD be set to zero. This bit is not used when selecting a MEG SBD-DR, i.e., it MUST be ignored by the receiver of an SBD-IMET route.
これらのSBD-IMETルートは、DF選挙ECも搭載する必要があります。DF選挙ECとその使用は[RFC8584]で指定されています。ルートが発信される場合、DF選挙ECのAC-DFビットはゼロに設定する必要があります。このビットは、MEG SBD-DRを選択するときは使用されません。つまり、SBD-IMETルートの受信機によって無視する必要があります。
In the context of a given Tenant Domain, to select the MEG SBD-DR, the MEGs of the Tenant Domain perform the following procedure:
特定のテナントドメインのコンテキストでは、MEG SBD-DRを選択するために、テナントドメインのMEGSが次の手順を実行します。
* From the set of received SBD-IMET routes for the given Tenant Domain, determine the candidate set of PEs that support MEG functionality for that domain.
* 指定されたテナントドメインの受信したSBD-IMETルートのセットから、そのドメインのMEG機能をサポートするPESの候補セットを決定します。
* Select a DF election algorithm as specified in [RFC8584]. Some of the possible algorithms can be found, e.g., in [RFC7432], [RFC8584], and [EVPN-DF].
* [RFC8584]で指定されているDF選挙アルゴリズムを選択します。可能なアルゴリズムのいくつかは、[RFC7432]、[RFC8584]、および[EVPN-DF]など、たとえば見つけることができます。
* Apply the DF election algorithm (see [RFC8584]) to the candidate set of PEs. The winner becomes the MEG SBD-DR.
* DF選挙アルゴリズム（[RFC8584]を参照）をPESの候補セットに適用します。勝者はMEG SBD-DRになります。
Note that if a given PE supports IPMG (Section 6.1.2) or PEG (Section 6.1.4) functionality as well as MEG functionality, its SBD-IMET routes carry only one DF Election EC.
特定のPEがIPMG（セクション6.1.2）またはPEG（セクション6.1.4）の機能とMEG機能をサポートしている場合、SBD-IMETルートは1つのDF選挙ECのみを搭載していることに注意してください。
If multicast service to the outside sources and/or receivers is provided via the BGP-based Global Table Multicast (GTM) procedures of [RFC7716], the procedures of Section 6.1.2 can easily be adapted for EVPN/GTM interworking. The way to adapt the MVPN procedures to GTM is explained in [RFC7716].
[RFC7716]のBGPベースのグローバルテーブルマルチキャスト（GTM）手順を介して外部ソースおよび/または受信機へのマルチキャストサービスが提供される場合、セクション6.1.2の手順は、EVPN/GTMインターワーキングに簡単に適応できます。MVPN手順をGTMに適応させる方法は、[RFC7716]で説明されています。
As discussed, there may be receivers in an EVPN Tenant Domain that are interested in multicast flows whose sources are outside the EVPN Tenant Domain. Or there may be receivers outside an EVPN Tenant Domain that are interested in multicast flows whose sources are inside the Tenant Domain.
説明したように、EVPNテナントドメインには、ソースがEVPNテナントドメインの外側にあるマルチキャストフローに関心のあるレシーバーが存在する場合があります。または、ソースがテナントドメイン内にあるマルチキャストフローに関心のあるEVPNテナントドメインの外にレシーバーがある場合があります。
If the outside sources and/or receivers are part of an MVPN, see the procedures for interworking that are covered in Section 6.1.2.
外部のソースおよび/または受信機がMVPNの一部である場合、セクション6.1.2でカバーされているインターワーキングの手順を参照してください。
There are also cases where an external source or receiver are attached via IP and the Layer 3 multicast routing is done via PIM. In this case, the interworking between the PIM domain and the EVPN Tenant Domain is done at L3 Gateways that perform PIM/EVPN Gateway (PEG) functionality. A PEG is very similar to a MEG, except that its Layer 3 multicast routing is done via PIM rather than via BGP.
また、外部ソースまたはレシーバーがIPを介して接続され、レイヤー3マルチキャストルーティングがPIMを介して行われる場合もあります。この場合、PIMドメインとEVPNテナントドメイン間のインターワーキングは、PIM/EVPNゲートウェイ（PEG）機能を実行するL3ゲートウェイで行われます。PEGはMEGに非常に似ていますが、そのレイヤー3マルチキャストルーティングはBGPではなくPIMを介して行われます。
If external sources or receivers for a given group are attached to a PEG via a Layer 3 interface, that interface should be treated as a VRF interface attached to the Tenant Domain's L3VPN VRF. The Layer 3 multicast routing instance for that Tenant Domain will either run PIM on the VRF interface or listen for IGMP/MLD messages on that interface. If the external receiver is attached elsewhere on an IP network, the PE has to enable PIM on its interfaces to the backbone network. In both cases, the PE needs to perform PEG functionality, and its IMET routes must carry the Multicast Flags EC with the PEG flag set.
特定のグループの外部ソースまたは受信機がレイヤー3インターフェイスを介してPEGに接続されている場合、そのインターフェイスは、テナントドメインのL3VPN VRFに接続されたVRFインターフェイスとして扱う必要があります。そのテナントドメインのレイヤー3マルチキャストルーティングインスタンスは、VRFインターフェイスでPIMを実行するか、そのインターフェイスでIGMP/MLDメッセージをリッスンします。外部レシーバーがIPネットワーク上の他の場所に接続されている場合、PEはバックボーンネットワークへのインターフェイスでPIMを有効にする必要があります。どちらの場合も、PEはPEG機能を実行する必要があり、そのIMETルートはPEGフラグセットを使用してマルチキャストフラグECを運ぶ必要があります。
For each BD on which there is a multicast source or receiver, one of the PEGs will become the PEG DR. DR selection can be done using the same procedures specified in Section 6.1.2.4, except with PEG substituted for MEG.
マルチキャストソースまたはレシーバーがある各BDについて、PEGの1つがPEG DRになります。DR選択は、MEGに置き換えられたPEGを除き、セクション6.1.2.4で指定されたのと同じ手順を使用して行うことができます。
As long as there are no tenant multicast routers within the EVPN Tenant Domain, the PEGs do not need to run PIM on their IRB interfaces.
EVPNテナントドメイン内にテナントマルチキャストルーターがない限り、PEGはIRBインターフェイスでPIMを実行する必要はありません。
If a PEG receives a PIM Join (S,G) from outside the EVPN Tenant Domain, it may find it necessary to create (S,G) state. The PE needs to determine whether S is within the Tenant Domain. If S is not within the EVPN Tenant Domain, the PE carries out normal Layer 3 multicast routing procedures. If S is within the EVPN Tenant Domain, the IIF of the (S,G) state is set as follows:
PEGがEVPNテナントドメインの外側からPIM結合（S、G）を受信した場合、（s、g）状態を作成する必要がある場合があります。PEは、Sがテナントドメイン内にあるかどうかを判断する必要があります。SがEVPNテナントドメイン内にない場合、PEは通常のレイヤー3マルチキャストルーティング手順を実行します。SがEVPNテナントドメイン内にある場合、（s、g）状態のIIFは次のように設定されています。
* If S is on a BD that is attached to the PE, the IIF is the PE's IRB interface to that BD.
* SがPEに接続されているBD上にある場合、IIFはそのBDへのPEのIRBインターフェイスです。
* If S is not on a BD that is attached to the PE, the IIF is the PE's IRB interface to the SBD.
* SがPEに接続されているBD上にSがない場合、IIFはSBDへのPEのIRBインターフェイスです。
When the PE creates such an (S,G) state, it MUST originate (if it hasn't already) an SBD-SMET route for (S,G). This will cause it to pull the (S,G) traffic via Layer 2. When the traffic arrives over an EVPN tunnel, it gets sent up an IRB interface where the Layer 3 multicast routing determines the packet's disposition. The SBD-SMET route is withdrawn when the (S,G) state no longer exists (unless there is some other reason for not withdrawing it).
PEがそのような（s、g）状態を作成する場合、（s、g）のsbd-smetルートを（まだ持っていない場合）発生する必要があります。これにより、レイヤー2を介して（s、g）トラフィックを引っ張ります。トラフィックがEVPNトンネル上に到着すると、レイヤー3マルチキャストルーティングがパケットの処分を決定するIRBインターフェイスが送信されます。（s、g）状態が存在しなくなった場合、SBD-Smetルートは撤回されます（撤回しない他の理由がない限り）。
If there are no tenant multicast routers within the EVPN Tenant Domain, there cannot be an RP in the Tenant Domain, so a PEG does not have to handle externally arriving PIM Join (*,G) messages.
EVPNテナントドメイン内にテナントマルチキャストルーターがない場合、テナントドメインにRPが存在できないため、PEGは外部から到着するPIM結合（*、g）メッセージを処理する必要がありません。
The PEG DR for a particular BD MUST act as the a First Hop Router for that BD. It will examine all (S,G) traffic on the BD, and whenever G is an ASM group, the PEG DR will send Register messages to the RP for G. This means that the PEG DR will need to pull all the (S,G) traffic originating on a given BD by originating a SMET (*,*) route for that BD. If a PEG DR is the DR for all the BDs, it SHOULD originate just an SBD-SMET (*,*) route rather than a SMET (*,*) route for each BD.
特定のBDのPEG DRは、そのBDの最初のホップルーターとして機能する必要があります。BDのすべての（S、G）トラフィックを調べ、GがASMグループである場合、PEG DRはGのRPにレジスタメッセージを送信します。これは、PEG DRがすべてを引く必要があることを意味します。g）そのBDのSMET（*、*）ルートを発信することにより、特定のBDで発信されるトラフィック。PEG DRがすべてのBDSのDRである場合、各BDのSMET（*、*）ルートではなく、SBD-Smet（*、*）ルートのみを発信する必要があります。
The rules for exporting IP routes to multicast sources are the same as those specified for MEGs in Section 6.1.2.2, except that the exported routes will be IP routes rather than VPN-IP routes, and it is not necessary to attach the VRF Route Import EC or the Source AS EC.
IPルートをマルチキャストソースにエクスポートするためのルールは、セクション6.1.2.2のMEGSに指定されたルールと同じです。ただし、エクスポートされたルートはVPN-IPルートではなくIPルートになることを除き、VRFルートインポートを接続する必要はありません。ECまたはSOURCE AS EC。
When a source is on a multihomed segment, the same issue discussed in Section 6.1.2.2.3 exists. Suppose S is on an Ethernet segment, belonging to BD1, that is multihomed to both PE1 and PE2, where PE1 is a PEG. And suppose that IP multicast traffic from S to G travels over the AC that attaches the segment to PE2. If PE1 receives an external PIM Join (S,G) route, it MUST originate a SMET route for (S,G). Normal OISM procedures will cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will also cause PE1 to send the (S,G) traffic up its BD1 IRB interface. Normal PIM procedures will then cause PE1 to forward the traffic along a PIM tree. In this case, the routing is not optimal, but the traffic does flow correctly.
ソースがマルチホームセグメントにある場合、セクション6.1.2.2.3で説明した同じ問題が存在します。SがBD1に属するイーサネットセグメントにあると仮定します。これは、PE1とPE2の両方にマルチホームされており、PE1はPEGです。また、SからGへのIPマルチキャストトラフィックが、セグメントをPE2に接続するACを越えて移動すると仮定します。PE1が外部PIM結合（S、G）ルートを受信する場合、（S、G）のSMETルートを発信する必要があります。通常のOISM手順により、PE2はEVPN IPマルチキャストトンネルで（s、g）トラフィックをPE1に送信します。また、通常のOISM手順により、PE1はBD1 IRBインターフェイスに（s、g）トラフィックを送信します。通常のPIM手順により、PE1がPIMツリーに沿ってトラフィックを転送します。この場合、ルーティングは最適ではありませんが、トラフィックは正しく流れます。
By means of normal OISM procedures, a PEG learns whether there are receivers in the Tenant Domain that are interested in receiving (*,G) or (S,G) traffic. The PEG must determine whether or not S (or the RP for G) is outside the EVPN Tenant Domain. If so, and if there is a receiver on BD1 interested in receiving such traffic, the PEG DR for BD1 is responsible for originating a PIM Join (S,G) or Join (*,G) control message.
通常のOISM手順により、PEGは、受信（*、g）または（s、g）トラフィックに関心のあるテナントドメインにレシーバーがあるかどうかを学びます。PEGは、S（またはGのRP）がEVPNテナントドメインの外側にあるかどうかを判断する必要があります。その場合、およびそのようなトラフィックの受信に関心のあるBD1にレシーバーがある場合、BD1のPEG DRは、PIM結合（S、G）または結合（*、G）コントロールメッセージを発信する責任があります。
An alternative would be to allow any PEG that is directly attached to a receiver to originate the PIM Joins. Then, the PEG DR would only have to originate PIM Joins on behalf of receivers that are not attached to a PEG. However, if this is done, it is necessary for the PEGs to run PIM on all their IRB interfaces so that the PIM Assert procedures can be used to prevent duplicate delivery to a given BD.
別の方法は、受信機に直接接続されているPEGがPIM結合を開始することを許可することです。その後、PEG DRは、PEGに取り付けられていないレシーバーに代わってPIM結合を発信するだけで必要です。ただし、これが行われた場合は、PEGがすべてのIRBインターフェイスでPIMを実行して、特定のBDへの重複配信を防ぐためにPIMアサート手順を使用できるようにする必要があります。
The IIF for the Layer 3 (S,G) or (*,G) state is determined by normal PIM procedures. If a receiver is on BD1, and the PEG DR is attached to BD1, its IRB interface to BD1 is added to the OIF list. This ensures that any receivers locally attached to the PEG DR will receive the traffic. If there are receivers attached to other EVPN PEs, then whenever (S,G) traffic from an external source matches a (*,G) state, the PEG will create (S,G) state. The IIF will be set to whatever external interface the traffic is expected to arrive on (copied from the (*,G) state), the OIF list is copied from the (*,G) state, and the SBD IRB interface is added to the OIF list.
レイヤー3（s、g）または（*、g）状態のIIFは、通常のPIM手順によって決定されます。受信機がBD1にあり、PEG DRがBD1に接続されている場合、BD1へのIRBインターフェイスがOIFリストに追加されます。これにより、PEG DRに局所的に接続されているレシーバーがトラフィックを受け取ることが保証されます。他のEVPN PESに接続されているレシーバーがある場合、外部ソースからのトラフィックが（*、g）状態に一致する場合、PEGは（s、g）状態を作成します。IIFは、トラフィックが到着すると予想される外部インターフェイス（（*、g）状態からコピー）に設定され、OIFリストは（*、g）状態からコピーされ、SBD IRBインターフェイスが追加されます。OIFリスト。
Section 6.1 describes how to use an OISM PE router as the gateway to a non-EVPN multicast domain when the EVPN Tenant Domain is not being used as an intermediate transit network for multicast. An alternative approach is to have one or more external PIM routers (perhaps operated by a tenant) on one of the BDs of the Tenant Domain. We will refer to this BD as the "gateway BD".
セクション6.1では、EVPNテナントドメインがマルチキャストの中間トランジットネットワークとして使用されていない場合、EVPNマルチキャストドメインのゲートウェイとしてOISM PEルーターを使用する方法について説明します。別のアプローチは、テナントドメインのBDSの1つに1つ以上の外部PIMルーター（おそらくテナントが操作する）を持つことです。このBDを「ゲートウェイBD」と呼びます。
In this model:
このモデルで：
* The EVPN Tenant Domain is treated as a stub network attached to the external PIM routers.
* EVPNテナントドメインは、外部PIMルーターに接続されたスタブネットワークとして扱われます。
* The external PIM routers follow normal PIM procedures and provide the FHR and LHR functionality for the entire Tenant Domain.
* 外部PIMルーターは、通常のPIM手順に従い、テナントドメイン全体にFHRおよびLHR機能を提供します。
* The OISM PEs do not run PIM.
* oism pesはpimを実行しません。
* There MUST NOT be more than one gateway BD.
* 複数のゲートウェイbdがないはずです。
* If an OISM PE not attached to the gateway BD has interest in a given multicast flow, it conveys that interest, following normal OISM procedures, by originating an SBD-SMET route for that flow.
* Gateway BDに添付されていないOISM PEが特定のマルチキャストフローに関心がある場合、そのフローのSBDスメットルートを発信することにより、通常のOISM手順に従ってその関心を伝えます。
* If a PE attached to the gateway BD receives an SBD-SMET, it may need to generate and transmit a corresponding IGMP/MLD Join on one or more of its ACs. (Procedures for generating an IGMP/MLD Join as a result of receiving a SMET route are given in [RFC9251].) The PE MUST know which BD is the gateway BD and MUST NOT transmit an IGMP/MLD Join to any other BDs. Furthermore, even if a particular AC is part of that BD, the PE SHOULD NOT transmit an IGMP/MLD Join on that AC unless there is an external PIM router attached via that AC.
* ゲートウェイBDに接続されたPEがSBDスメットを受信した場合、対応するIGMP/MLDを生成および送信する必要がある場合があります。（[RFC9251]でSMETルートを受け取った結果としてIGMP/MLD結合を生成する手順。）PEは、どのBDがゲートウェイBDであるかを知っている必要があり、IGMP/MLD結合を他のBDに送信してはなりません。さらに、特定のACがそのBDの一部である場合でも、PEはそのACを介して外部PIMルーターが接続されていない限り、そのACにIGMP/MLD結合を送信する必要はありません。
As a result, IGMP/MLD messages will be received by the external PIM routers on the gateway BD, and those external PIM routers will send PIM Join messages externally as required. Traffic for the given multicast flow will then be received by one of the external PIM routers, and that traffic will be forwarded by that router to the gateway BD.
その結果、IGMP/MLDメッセージはゲートウェイBDの外部PIMルーターによって受信され、それらの外部PIMルーターは必要に応じてPIM結合メッセージを外部から送信します。特定のマルチキャストフローのトラフィックは、外部PIMルーターの1つによって受信され、そのトラフィックはそのルーターによってゲートウェイBDに転送されます。
The normal OISM procedures will then cause the given multicast flow to be tunneled to any PEs of the EVPN Tenant Domain that have interest in the flow. PEs attached to the gateway BD will see the flow as originating from the gateway BD, and other PEs will see the flow as originating from the SBD.
次に、通常のOISM手順により、与えられたマルチキャストフローが、フローに関心のあるEVPNテナントドメインのPESにトンネル化されます。ゲートウェイBDに接続されたPESは、ゲートウェイBDからの流れを確認し、他のPESはSBDに由来するフローを見ることができます。
* An OISM PE attached to a gateway BD MUST set its Layer 2 multicast state to indicate that each AC to the gateway BD has interest in all multicast flows. It MUST also originate a SMET route for (*,*). The procedures for originating SMET routes are discussed in Section 2.5.
* ゲートウェイBDに接続されたOISM PEは、各ACがゲートウェイBDへの各ACがすべてのマルチキャストフローに関心があることを示すために、レイヤー2マルチキャスト状態を設定する必要があります。また、（*、*）のSMETルートを発生する必要があります。SMETルートの発生手順については、セクション2.5で説明します。
This will cause the OISM PEs attached to the gateway BD to receive all the IP multicast traffic that is sourced within the EVPN Tenant Domain and to transmit that traffic to the gateway BD, where the external PIM routers will receive it. This enables the external PIM routers to perform FHR functions on behalf of the entire Tenant Domain. (Of course, if the gateway BD has a multihomed segment, only the PE that is the DF for that segment will transmit the multicast traffic to the segment.)
これにより、Gateway BDに接続されたOISM PESがEVPNテナントドメイン内で調達されたすべてのIPマルチキャストトラフィックを受信し、外部PIMルーターが受信するゲートウェイBDにそのトラフィックを送信します。これにより、外部PIMルーターがテナントドメイン全体に代わってFHR関数を実行できます。（もちろん、ゲートウェイBDにマルチホームセグメントがある場合、そのセグメントのDFであるPEのみがマルチキャストトラフィックをセグメントに送信します。）
In this section, we consider the scenario where one or more BDs of an EVPN Tenant Domain are being used to carry IP multicast traffic for which the source and at least one receiver are not part the Tenant Domain. That is, one or more BDs of the Tenant Domain are intermediate links of a larger multicast tree created by PIM.
このセクションでは、EVPNテナントドメインの1つ以上のBDSが、ソースと少なくとも1つのレシーバーがテナントドメインの一部ではないIPマルチキャストトラフィックを運ぶために使用されるシナリオを検討します。つまり、テナントドメインの1つ以上のBDSは、PIMによって作成された大きなマルチキャストツリーの中間リンクです。
We define a "tenant multicast router" as a multicast router, running PIM, that:
「テナントマルチキャストルーター」をマルチキャストルーターとして定義し、PIMを実行しています。
1. is attached to one or more BDs of the Tenant Domain but
1. テナントドメインの1つ以上のBDSに接続されていますが
2. is not an EVPN PE router.
2. EVPN PEルーターではありません。
In order for an EVPN Tenant Domain to be used as a transit network for IP multicast, one or more of its BDs must have tenant multicast routers, and an OISM PE attached to such a BD MUST be provisioned to enable PIM on its IRB interface to that BD. (This is true even if none of the tenant routers is on a segment attached to the PE.) Further, all the OISM PEs (even ones not attached to a BD with tenant multicast routers) MUST be provisioned to enable PIM on their SBD IRB interfaces.
EVPNテナントドメインをIPマルチキャストのトランジットネットワークとして使用するには、1つ以上のBDSがテナントマルチキャストルーターを備えている必要があり、そのようなBDに接続されたOISM PEをIRBインターフェイスでPIMを有効にするためにプロビジョニングする必要があります。そのbd。（これは、テナントルーターがPEに接続されたセグメントにない場合でも当てはまります。）さらに、SBD IRBでPIMを有効にするために、すべてのOISM PE（テナントマルチキャストルーターを使用してBDに接続していないものでも）をプロビジョニングする必要があります。インターフェイス。
If PIM is enabled on a particular BD, the DR selection procedure of Section 6.1.2.4 MUST be replaced by the normal PIM DR Election procedure of [RFC7761]. Note that this may result in one of the tenant routers being selected as the DR rather than one of the OISM PE routers. In this case, First Hop Router and Last Hop Router functionality will not be performed by any of the EVPN PEs.
PIMが特定のBDで有効になっている場合、セクション6.1.2.4のDR選択手順は、[RFC7761]の通常のPIM DR選挙手順に置き換える必要があります。これにより、テナントルーターの1つがOISM PEルーターの1つではなくDRとして選択される可能性があることに注意してください。この場合、最初のホップルーターと最後のホップルーター機能は、EVPN PESのいずれによっても実行されません。
A PIM control message on a particular BD is considered to be a link-local multicast message and, as such, is sent transparently from PE to PE via the BUM tunnel for that BD. This is true whether the control message was received from an AC or from the local Layer 3 routing instance via an IRB interface.
特定のBDのPIMコントロールメッセージは、Link-Local Multicastメッセージと見なされ、そのため、そのBDのBumトンネルを介してPEからPEに透過的に送信されます。これは、制御メッセージがACから受信されたか、IRBインターフェイスを介してローカルレイヤー3ルーティングインスタンスから受信されたかどうかに当てはまります。
A PIM Join/Prune message contains three fields that are relevant to the present discussion:
PIM Join/Pruneメッセージには、現在の議論に関連する3つのフィールドが含まれています。
* Upstream Neighbor
* 上流の隣人
* Group Address (G)
* グループアドレス（g）
* Source Address (S), omitted in the case of (*,G) Join/Prune messages
* ソースアドレス（*、g）の場合に省略されています。
We will generally speak of a PIM Join as a Join (S,G) or a Join (*,G) message and will use the term "Join (X,G)" to mean either "Join (S,G)" or "Join (*,G)". In the context of a Join (X,G), we will use the term "X" to mean "S" in the case of (S,G) or "G's RP" in the case of (*,G).
通常、PIM結合についてJoin（s、g）またはJoin（*、g）メッセージとして話し、「Join（x、g）」という用語を使用して、「Join（s、g）」または「結合（*、g）」。結合（x、g）のコンテキストでは、（*、g）の場合、（s、g）または「g's rp」の場合、「x」という用語を使用して「s」を意味します。
Suppose BD1 contains two tenant multicast routers, say C1 and C2. Suppose C1 is on a segment attached to PE1 and C2 is on a segment attached to PE2. When C1 sends a PIM Join (X,G) to BD1, the Upstream Neighbor field might be set to PE1, PE2, or C2. C1 chooses the Upstream Neighbor based on its unicast routing. Typically, it will choose the PIM router on BD1 that is closest (according to the unicast routing) to X as the Upstream Neighbor. Note that this will not necessarily be PE1. PE1 may not even be visible to the unicast routing algorithm used by the tenant routers. Even if it is, it is unlikely to be the PIM router that is closest to X. So we need to consider the following two cases:
BD1が2つのテナントマルチキャストルーター、たとえばC1とC2が含まれているとします。C1がPE1に接続されたセグメントにあると仮定し、C2がPE2に接続されたセグメントにあります。C1がPIM結合（x、g）をBD1に送信すると、上流の隣接フィールドはPE1、PE2、またはC2に設定されます。C1は、ユニキャストルーティングに基づいて上流の隣人を選択します。通常、上流の隣接としてXに最も近い（ユニキャストルーティングに従って）BD1のPIMルーターを選択します。これは必ずしもPE1ではないことに注意してください。PE1は、テナントルーターが使用するユニキャストルーティングアルゴリズムにさえ見えない場合があります。たとえそうであっても、Xに最も近いPIMルーターである可能性は低い。したがって、次の2つのケースを考慮する必要があります。
1. C1 sends a PIM Join (X,G) to BD1, with PE1 as the Upstream Neighbor.
1. C1は、PE1を上流の隣接として、PIM結合（x、g）をBD1に送信します。
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB interface. If X is not within the Tenant Domain, PE1 handles the Join according to normal PIM procedures. This will generally result in PE1 selecting an Upstream Neighbor and sending it a Join (X,G).
PE1のPIMルーティングインスタンスは、BD1 IRBインターフェイスのJoint Ardentを受信します。xがテナントドメイン内にない場合、PE1は通常のPIM手順に従って結合を処理します。これにより、通常、PE1が上流の隣人を選択し、結合（x、g）を送信します。
If X is within the Tenant Domain but is attached to some other PE, PE1 sends (if it hasn't already) an SBD-SMET route for (X,G). The IIF of the Layer 3 (X,G) state will be the SBD IRB interface, and the OIF list will include the IRB interface to BD1.
xがテナントドメイン内にあるが、他のPEに接続されている場合、PE1は（まだ持っていない場合）（x、g）のSBDスメットルートを送信します。レイヤー3（x、g）状態のIIFはSBD IRBインターフェイスになり、OIFリストにはBD1へのIRBインターフェイスが含まれます。
The SBD-SMET route will pull the (X,G) traffic to PE1, and the (X,G) state will result in the (X,G) traffic being forwarded to C1.
SBD-Smetルートは（x、g）トラフィックをPE1に引き込み、（x、g）状態は（x、g）トラフィックがC1に転送されます。
If X is within the Tenant Domain but is attached to PE1 itself, no SBD-SMET route is sent. The IIF of the Layer 3 (X,G) state will be the IRB interface to X's BD, and the OIF list will include the IRB interface to BD1.
xがテナントドメイン内にあるが、PE1自体に接続されている場合、SBD-Smetルートは送信されません。レイヤー3（x、g）状態のIIFは、xのBDへのIRBインターフェイスとなり、OIFリストにはBD1へのIRBインターフェイスが含まれます。
2. C1 sends a PIM Join (X,G) to BD1, with either PE2 or C2 as the Upstream Neighbor.
2. C1は、上流の隣接としてPE2またはC2を使用して、PIM結合（x、g）をBD1に送信します。
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB interface. If neither X nor Upstream Neighbor is within the Tenant Domain, PE1 handles the Join according to normal PIM procedures. This will NOT result in PE1 sending a Join (X,G).
PE1のPIMルーティングインスタンスは、BD1 IRBインターフェイスのJoint Ardentを受信します。Xも上流の隣人もテナントドメイン内にない場合、PE1は通常のPIM手順に従って結合を処理します。これにより、PE1が結合（x、g）を送信することはありません。
If either X or Upstream Neighbor is within the Tenant Domain, PE1 sends (if it hasn't already) an SBD-SMET route for (X,G). The IIF of the Layer 3 (X,G) state will be the SBD IRB interface, and the OIF list will include the IRB interface to BD1.
xまたは上流の隣人のいずれかがテナントドメイン内にある場合、PE1は（x、g）のSBDスメットルートを（まだ持っていない場合）送信します。レイヤー3（x、g）状態のIIFはSBD IRBインターフェイスになり、OIFリストにはBD1へのIRBインターフェイスが含まれます。
The SBD-SMET route will pull the (X,G) traffic to PE1, and the (X,G) state will result in the (X,G) traffic being forwarded to C1.
SBD-Smetルートは（x、g）トラフィックをPE1に引き込み、（x、g）状態は（x、g）トラフィックがC1に転送されます。
IANA has assigned new flags in the "Multicast Flags Extended Community" registry under the "Border Gateway Protocol (BGP) Extended Communities" registry as shown below.
IANAは、以下に示すように、「Border Gateway Protocol（BGP）Extended Communities」レジストリの下で、「マルチキャストフラグ拡張コミュニティ」レジストリに新しいフラグを割り当てました。
+=====+================+===========+===================+
| Bit | Name | Reference | Change Controller |
+=====+================+===========+===================+
| 7 | OISM SBD | RFC 9625 | IETF |
+-----+----------------+-----------+-------------------+
| 9 | IPMG | RFC 9625 | IETF |
+-----+----------------+-----------+-------------------+
| 10 | MEG | RFC 9625 | IETF |
+-----+----------------+-----------+-------------------+
| 11 | PEG | RFC 9625 | IETF |
+-----+----------------+-----------+-------------------+
| 12 | OISM-supported | RFC 9625 | IETF |
+-----+----------------+-----------+-------------------+
Table 1: Multicast Flags Extended Community Registry
表1：マルチキャストフラグ拡張コミュニティレジストリ
This document uses protocols and procedures defined in the normative references and inherits the security considerations of those references.
このドキュメントは、規範的参照で定義されたプロトコルと手順を使用し、それらの参照のセキュリティ上の考慮事項を継承します。
This document adds flags or Extended Communities (ECs) to a number of BGP routes in order to signal that particular nodes support the OISM, IPMG, MEG, and/or PEG functionalities that are defined in this document. Incorrect addition, removal, or modification of those flags and/or ECs will cause the procedures defined herein to malfunction, in which case loss or diversion of data traffic is possible. Implementations should provide tools to easily debug configuration mistakes that cause the signaling of incorrect information.
このドキュメントでは、特定のノードがこのドキュメントで定義されているOISM、IPMG、MEG、および/またはPEG機能をサポートすることを示すために、フラグまたは拡張コミュニティ（ECS）を多くのBGPルートに追加します。これらのフラグおよび/またはECの追加、削除、または変更は、ここで定義されている手順を誤動作に引き起こします。この場合、データトラフィックの損失または転換が可能になります。実装は、誤った情報の信号を引き起こす構成ミスを簡単にデバッグするツールを提供する必要があります。
The interworking with non-OISM networks described in Sections 5 and 6 requires gateway functions in multiple redundant PEs, among which one of them is elected as Designated Forwarder for a given BD (or SBD). The election of the MEG or PEG DR, as well as the IPMG Designated Forwarder, makes use of the Designated Forwarder election procedures [RFC8584]. An attacker with access to one of these Gateways may influence such election and therefore modify the forwarding of multicast traffic between the OISM network and the external domain. The operator should be especially careful with the protection of these gateways by making sure the management interfaces to access the gateways are only allowed to authorized operators.
セクション5および6で説明されている非OISMネットワークとの相互作用には、複数の冗長PESでゲートウェイ関数が必要であり、そのうちの1つは特定のBD（またはSBD）の指定されたフォワーダーとして選出されます。MEGまたはPEG DRの選出、およびIPMG指定フォワーダーは、指定されたフォワーダー選挙手続き[RFC8584]を利用しています。これらのゲートウェイのいずれかにアクセスできる攻撃者は、そのような選挙に影響を与える可能性があり、したがって、OISMネットワークと外部ドメイン間のマルチキャストトラフィックの転送を変更する可能性があります。オペレーターは、ゲートウェイにアクセスするための管理インターフェイスが許可されたオペレーターのみに許可されていることを確認することにより、これらのゲートウェイの保護に特に注意する必要があります。
The document also introduces the concept of per-Tenant-Domain dissemination for the SMET routes, as opposed to per-BD distribution in [RFC9251]. That is, a SMET route triggered by the reception of an IGMP/MLD Join in BD-1 on PE1 needs to be distributed and imported by all PEs of the Tenant Domain, even to those PEs that are not attached to BD-1. This means that an attacker with access to only one BD in a PE of the Tenant Domain might force the advertisement of SMET routes and impact the resources of all the PEs of the Tenant Domain, as opposed to only the PEs of that particular BD (as in [RFC9251]). The implementation should provide ways to filter/control the client IGMP/ MLD reports that are received by the attached hosts.
このドキュメントでは、[RFC9251]のBD分布とは対照的に、SMETルートのテナントごとのドメイン普及の概念も紹介しています。つまり、BD-1に接続されていないPESにも、IGMP/MLDがBD-1で結合するBD-1にPE1で結合することでトリガーされるSMETルートは、テナントドメインのすべてのPESによって分布およびインポートする必要があります。これは、テナントドメインのPEに1つのBDのみにアクセスできる攻撃者が、SMETルートの広告を強制し、テナントドメインのすべてのPESのリソースに影響を与える可能性があることを意味します。[RFC9251]）。実装は、添付のホストが受信したクライアントIGMP/ MLDレポートをフィルタリング/制御する方法を提供する必要があります。
[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>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[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>.
[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>.
[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>.
[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>.
[EVPN-DF] Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.
Sajassi, "Preference-based EVPN DF Election", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,
9 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-pref-df-13>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[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>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
and D. Pacella, "Global Table Multicast with BGP Multicast
VPN (BGP-MVPN) Procedures", RFC 7716,
DOI 10.17487/RFC7716, December 2015,
<https://www.rfc-editor.org/info/rfc7716>.
[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>.
[RFC9624] Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using
Bit Index Explicit Replication (BIER)", RFC 9624,
DOI 10.17487/RFC9624, August 2024,
<https://www.rfc-editor.org/info/rfc9624>.
This appendix provides a short tutorial on the interaction of routing and bridging. First, it shows a model, where bridging and routing are performed in separate devices. Then, it shows the model specified in [RFC9135], where a single device contains both routing and bridging functions. The latter model is presupposed in the body of this document.
この付録は、ルーティングとブリッジングの相互作用に関する短いチュートリアルを提供します。まず、別々のデバイスでブリッジングとルーティングが実行されるモデルを表示します。次に、[RFC9135]で指定されたモデルを示します。ここでは、単一のデバイスにはルーティング機能とブリッジング機能の両方が含まれています。後者のモデルは、この文書の本文で前提とされています。
Figure 2 shows the model where a router only does routing and has no L2 bridging capabilities. There are two LANs: LAN1 and LAN2. LAN1 is realized by switch1, and LAN2 is realized by switch2. The router has an interface, lan1, that attaches to LAN1 (via switch1) and an interface, lan2, that attaches to LAN2 (via switch2). Each interface is configured, as an IP interface, with an IP address and a subnet mask.
図2は、ルーターがルーティングのみを行い、L2ブリッジング機能がないモデルを示しています。LANとLAN2の2つのLANがあります。LAN1はSwitch1によって実現され、LAN2はSwitch2によって実現されます。ルーターには、lan1（switch1を介して）に付着するインターフェイスlan1とlan2（switch2を介して）に付着するインターフェイスlan2があります。各インターフェイスは、IPアドレスとサブネットマスクを備えたIPインターフェイスとして構成されています。
+-------+ +--------+ +-------+
| | lan1| |lan2 | |
H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3
| | | | | |
H2 -----| | | | | |
+-------+ +--------+ +-------+
|_________________| |__________________|
LAN1 LAN2
Figure 2: Conventional Router with LAN Interfaces
図2：LANインターフェイスを備えた従来のルーター
IP traffic (unicast or multicast) that remains within a single subnet never reaches the router. For instance, if H1 emits an Ethernet frame with H2's MAC address in the Ethernet Destination Address field, the frame will go from H1 to Switch1 to H2 without ever reaching the router. Since the frame is never seen by a router, the IP datagram within the frame remains entirely unchanged, e.g., its TTL is not decremented. The Ethernet Source and Destination MAC addresses are not changed either.
単一のサブネット内に残るIPトラフィック（ユニキャストまたはマルチキャスト）は、ルーターに到達することはありません。たとえば、H1がイーサネット宛先アドレスフィールドにH2のMACアドレスを持つイーサネットフレームを発した場合、フレームはルーターに到達することなくH1からSwitch1にH2に移動します。フレームはルーターでは見られないため、フレーム内のIPデータグラムはまったく変更されていません。たとえば、TTLは減少していません。イーサネットソースと宛先MACアドレスも変更されません。
If H1 wants to send a unicast IP datagram to H3, which is on a different subnet, H1 has to be configured with the IP address of a default router. Let's assume that H1 is configured with an IP address of Router1 as its default router address. H1 compares H3's IP address with its own IP address and IP subnet mask and determines that H3 is on a different subnet. So the packet has to be routed. H1 uses ARP to map Router1's IP address to a MAC address on LAN1. H1 then encapsulates the datagram in an Ethernet frame, using Router1's MAC address as the destination MAC address, and sends the frame to Router1.
H1がユニキャストIPデータグラムを別のサブネット上にあるH3に送信する場合、H1はデフォルトルーターのIPアドレスで構成する必要があります。H1がRouter1のIPアドレスをデフォルトルーターアドレスとして構成されていると仮定しましょう。H1は、H3のIPアドレスを独自のIPアドレスとIPサブネットマスクと比較し、H3が別のサブネット上にあると判断します。したがって、パケットをルーティングする必要があります。H1はARPを使用して、Router1のIPアドレスをLAN1のMACアドレスにマッピングします。H1は、Router1のMacアドレスを宛先MACアドレスとして使用して、イーサネットフレームのデータグラムをカプセル化し、フレームをRouter1に送信します。
Router1 then receives the frame over its lan1 interface. Router1 sees that the frame is addressed to it, so it removes the Ethernet encapsulation and processes the IP datagram. The datagram is not addressed to Router1, so it must be forwarded further. Router1 does a lookup of the datagram's IP Destination Address field and determines that the destination (H3) can be reached via Router1's lan2 interface. Router1 now performs the IP processing of the datagram: it decrements the IP TTL, adjusts the IP header checksum (if present), may fragment the packet as necessary, etc. Then, the datagram (or its fragments) is encapsulated in an Ethernet header, with Router1's MAC address on LAN2 as the MAC Source Address and H3's MAC address on LAN2 (which Router1 determines via ARP) as the Destination MAC Address. Finally, the packet is sent on the lan2 interface.
Router1は、LAN1インターフェイス上にフレームを受信します。Router1は、フレームに対処されていることを確認するため、イーサネットのカプセル化を削除し、IPデータグラムを処理します。データグラムはRouter1に宛てられていないため、さらに転送する必要があります。Router1は、DatagramのIP宛先アドレスフィールドを検索し、Router1のLAN2インターフェイスを介して宛先（H3）に到達できると判断します。Router1はデータグラムのIP処理を実行するようになりました。IPTTLを減少させ、IPヘッダーチェックサム（存在する場合）を調整し、必要に応じてパケットをフラグメントする可能性があります。、MACソースアドレスとしてLAN2のRouter1のMACアドレスを、LAN2のH3のMACアドレス（Router1がARPを介して決定する）を宛先MACアドレスとして備えています。最後に、パケットはLAN2インターフェイスに送信されます。
If H1 has an IP multicast datagram to send (i.e., an IP datagram whose Destination Address field is an IP Multicast Address), it encapsulates it in an Ethernet frame whose Destination MAC Address is computed from the IP Destination Address.
H1に送信するIPマルチキャストデータグラム（つまり、宛先アドレスフィールドがIPマルチキャストアドレスであるIPデータグラム）がある場合、IP宛先アドレスから宛先MACアドレスが計算されるイーサネットフレームにカプセル化します。
If H2 is a receiver for that multicast address, H2 will receive a copy of the frame, unchanged, from H1. The MAC Source Address in the Ethernet encapsulation does not change, the IP TTL field does not get decremented, etc.
H2がそのマルチキャストアドレスの受信機である場合、H2からH2はH1から変更されていないフレームのコピーを受け取ります。イーサネットカプセル化のMACソースアドレスは変更されず、IP TTLフィールドは減少しません。
If H3 is a receiver for that multicast address, the datagram must be routed to H3. In order for this to happen, Router1 must be configured as a multicast router, and it must accept traffic sent to Ethernet multicast addresses. Router1 will receive H1's multicast frame on its lan1 interface, remove the Ethernet encapsulation, and determine how to dispatch the IP datagram based on Router1's multicast forwarding states. If Router1 knows that there is a receiver for the multicast datagram on LAN2, it makes a copy of the datagram, decrements the TTL (and performs any other necessary IP processing), and then encapsulates the datagram in the Ethernet frame for LAN2. The MAC Source Address for this frame will be Router1's MAC Source Address on LAN2. The Destination MAC Address is computed from the IP Destination Address. Finally, the frame is sent on Router1's LAN2 interface.
H3がそのマルチキャストアドレスの受信機である場合、データグラムはH3にルーティングする必要があります。これを行うには、Router1をマルチキャストルーターとして構成する必要があり、イーサネットマルチキャストアドレスに送信されるトラフィックを受け入れる必要があります。Router1は、LAN1インターフェイスでH1のマルチキャストフレームを受信し、イーサネットのカプセル化を削除し、Router1のマルチキャスト転送状態に基づいてIPデータグラムをディスパッチする方法を決定します。router1がLAN2にマルチキャストデータグラムの受信機があることを知っている場合、データグラムのコピーを作成し、TTLを減少させ（および他の必要なIP処理を実行します）、LAN2のイーサネットフレームのデータグラムをカプセル化します。このフレームのMACソースアドレスは、LAN2のRouter1のMacソースアドレスです。宛先MACアドレスは、IP宛先アドレスから計算されます。最後に、フレームはRouter1のLAN2インターフェイスに送信されます。
Figure 3 shows an integrated router/bridge that supports the routing/ bridging integration model of [RFC9135].
図3は、[RFC9135]のルーティング/ブリッジング統合モデルをサポートする統合されたルーター/ブリッジを示しています。
+------------------------------------------+
| Integrated Router/Bridge |
+-------+ +--------+ +-------+
| | IRB1| L3 |IRB2 | |
H1 -----+ BD1 +--------+Routing +--------+ BD2 +------H3
| | |Instance| | |
H2 -----| | | | | |
+-------+ +--------+ +-------+
|___________________| |____________________|
LAN1 LAN2
Figure 3: Integrated Router/Bridge
図3：統合ルーター/ブリッジ
In Figure 3, a single device consists of one or more L3 Routing Instances. The routing/forwarding tables of a given routing instance is known as an IP-VRF [RFC9135]. In the context of EVPN, it is convenient to think of each routing instance as representing the routing of a particular tenant. Each IP-VRF is attached to one or more interfaces.
図3では、単一のデバイスは1つ以上のL3ルーティングインスタンスで構成されています。特定のルーティングインスタンスのルーティング/転送テーブルは、IP-VRF [RFC9135]として知られています。EVPNのコンテキストでは、各ルーティングインスタンスを特定のテナントのルーティングを表すものと考えるのが便利です。各IP-VRFは、1つ以上のインターフェイスに接続されています。
When several EVPN PEs have a routing instance of the same Tenant Domain, those PEs advertise IP routes to the attached hosts. This is done as specified in [RFC9135].
いくつかのEVPN PEが同じテナントドメインのルーティングインスタンスを持っている場合、それらのPEは添付のホストにIPルートを宣伝します。これは、[RFC9135]で指定されているとおりに行われます。
The integrated router/bridge shown in Figure 3 also attaches to a number of Broadcast Domains (BDs). Each BD performs the functions that are performed by the bridges in Figure 2. To the L3 routing instance, each BD appears to be a LAN. The interface attaching a particular BD to a particular IP-VRF is known as an "IRB interface". From the perspective of L3 routing, each BD is a subnet. Thus, each IRB interface is configured with a MAC address (which is the router's MAC address on the corresponding LAN), as well as an IP address and subnet mask.
図3に示す統合されたルーター/ブリッジは、多くのブロードキャストドメイン（BDS）にも付いています。各BDは、図2のブリッジによって実行される機能を実行します。L3ルーティングインスタンスには、各BDがLANのように見えます。特定のBDを特定のIP-VRFに取り付けるインターフェイスは、「IRBインターフェイス」として知られています。L3ルーティングの観点から見ると、各BDはサブネットです。したがって、各IRBインターフェイスは、MACアドレス（対応するLAN上のルーターのMACアドレスです）とIPアドレスとサブネットマスクで構成されています。
The integrated router/bridge shown in Figure 3 may have multiple ACs to each BD. These ACs are visible only to the bridging function, not to the routing instance. To the L3 routing instance, there is just one interface to each BD.
図3に示す統合されたルーター/ブリッジには、各BDに複数のACSがある場合があります。これらのACは、ルーティングインスタンスではなく、ブリッジ機能にのみ表示されます。L3ルーティングインスタンスには、各BDに1つのインターフェイスしかありません。
If the L3 routing instance represents the IP routing of a particular tenant, the BDs attached to that routing instance are BDs belonging to that same tenant.
L3ルーティングインスタンスが特定のテナントのIPルーティングを表す場合、そのルーティングインスタンスに接続されているBDSは、同じテナントに属するBDです。
Bridging and routing now proceed exactly as in the case of Figure 2, except that BD1 replaces Switch1, BD2 replaces Switch2, interface IRB1 replaces interface lan1, and interface IRB2 replaces interface lan2.
ブリッジングとルーティングは、図2の場合とまったく同じように進行するようになりましたが、BD1はSwitch1、BD2がSwitch2を置き換え、インターフェイスIRB1がインターフェイスLAN1を置き換え、インターフェイスIRB2はインターフェイスLAN2を置き換えます。
It is important to understand that an IRB interface connects an L3 routing instance to a BD, NOT to a MAC-VRF (see [RFC7432] for the definition of MAC-VRF). A MAC-VRF may contain several BDs, as long as no MAC address appears in more than one BD. From the perspective of the L3 routing instance, each individual BD is an individual IP subnet; whether or not each BD has its own MAC-VRF is irrelevant to the L3 routing instance.
IRBインターフェイスは、MAC-VRFの定義については[RFC7432]を参照）ではなく、L3ルーティングインスタンスをBDに接続することを理解することが重要です。MAC-VRFには、複数のBDにMACアドレスが表示されない限り、いくつかのBDが含まれる場合があります。L3ルーティングインスタンスの観点から見ると、各BDは個々のIPサブネットです。各BDに独自のMAC-VRFがあるかどうかは、L3ルーティングインスタンスとは無関係です。
Figure 4 illustrates IRB when a pair of BDs (subnets) are attached to two different PE routers. In this example, each BD has two segments, and one segment of each BD is attached to one PE router.
図4は、BDS（サブネット）のペアが2つの異なるPEルーターに接続されている場合のIRBを示しています。この例では、各BDには2つのセグメントがあり、各BDの1つのセグメントが1つのPEルーターに接続されています。
+------------------------------------------+
| Integrated Router/Bridges |
+-------+ +--------+ +-------+
| | IRB1| |IRB2 | |
H1 -----+ BD1 +--------+ PE1 +--------+ BD2 +------H3
|(Seg-1)| |(L3 Rtg)| |(Seg-1)|
H2 -----| | | | | |
+-------+ +--------+ +-------+
|___________________| | |____________________|
LAN1 | LAN2
|
|
+-------+ +--------+ +-------+
| | IRB1| |IRB2 | |
H4 -----+ BD1 +--------+ PE2 +--------+ BD2 +------H5
|(Seg-2)| |(L3 Rtg)| |(Seg-2)|
| | | | | |
+-------+ +--------+ +-------+
Figure 4: Integrated Router/Bridges with Distributed Subnet
図4：分散サブネットを備えた統合ルーター/ブリッジ
If H1 needs to send an IP packet to H4, it determines from its IP address and subnet mask that H4 is on the same subnet as H1. Although H1 and H4 are not attached to the same PE router, EVPN provides Ethernet communication among all hosts that are on the same BD. Thus, H1 uses ARP to find H4's MAC address and sends an Ethernet frame with H4's MAC address in the Destination MAC Address field. The frame is received at PE1, but since the Destination MAC address is not PE1's MAC address, PE1 assumes that the frame is to remain on BD1. Therefore, the packet inside the frame is NOT decapsulated and is NOT sent up the IRB interface to PE1's routing instance. Rather, standard EVPN intra-subnet procedures (as detailed in [RFC7432]) are used to deliver the frame to PE2, which then sends it to H4.
H1がIPパケットをH4に送信する必要がある場合、IPアドレスとサブネットマスクからH4がH1と同じサブネット上にあることを決定します。H1とH4は同じPEルーターに接続されていませんが、EVPNは同じBDにあるすべてのホスト間でイーサネット通信を提供します。したがって、H1はARPを使用してH4のMACアドレスを見つけ、宛先MACアドレスフィールドにH4のMACアドレスを持つイーサネットフレームを送信します。フレームはPE1で受信されますが、宛先MACアドレスはPE1のMACアドレスではないため、PE1はフレームがBD1に留まることを想定しています。したがって、フレーム内のパケットは脱カプセル化されておらず、IRBインターフェイスをPE1のルーティングインスタンスに送信しません。むしろ、標準のEVPNイントラサブネット手順（[RFC7432]で詳述されているとおり）を使用してフレームをPE2に届け、H4に送信します。
If H1 needs to send an IP packet to H5, it determines from its IP address and subnet mask that H5 is NOT on the same subnet as H1. Assuming that H1 has been configured with the IP address of PE1 as its default router, H1 sends the packet in an Ethernet frame with PE1's MAC address in its Destination MAC Address field. PE1 receives the frame and sees that the frame is addressed to it. Thus, PE1 sends the frame up its IRB1 interface to the L3 routing instance. Appropriate IP processing is done, e.g., TTL decrement. The L3 routing instance determines that the next hop for H5 is PE2, so the packet is encapsulated (e.g., in MPLS) and sent across the backbone to PE2's routing instance. PE2 will see that the packet's destination, H5, is on BD2 segment-2 and will send the packet down its IRB2 interface. This causes the IP packet to be encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in the Source Address field and H5's MAC address in the Destination Address field.
H1がIPパケットをH5に送信する必要がある場合、IPアドレスとサブネットマスクからH5がH1と同じサブネットにないことを決定します。H1がデフォルトルーターとしてPE1のIPアドレスで構成されていると仮定すると、H1は宛先MACアドレスフィールドにPE1のMACアドレスを備えたイーサネットフレームにパケットを送信します。PE1はフレームを受け取り、フレームに対処されていることがわかります。したがって、PE1はフレームをIRB1インターフェイスにL3ルーティングインスタンスに送信します。適切なIP処理が行われます。たとえば、TTLの減少。L3ルーティングインスタンスは、H5の次のホップがPE2であると判断しているため、パケットがカプセル化（MPLSなど）にカプセル化され、バックボーンを介してPE2のルーティングインスタンスに送信されます。PE2は、パケットの宛先H5がBD2セグメント2にあることを確認し、IRB2インターフェイスをパケットに送信します。これにより、IPパケットは、ソースアドレスフィールドにPE2のMACアドレス（BD2）と宛先アドレスフィールドにH5のMACアドレスを備えたイーサネットフレームにカプセル化されます。
Note that if H1 has an IP packet to send to H3, the forwarding of the packet is handled entirely within PE1. PE1's routing instance sees the packet arrive on its IRB1 interface and then transmits the packet by sending it down its IRB2 interface.
H1にH3に送信するIPパケットがある場合、パケットの転送は完全にPE1内で処理されることに注意してください。PE1のルーティングインスタンスでは、パケットがIRB1インターフェイスに到着し、IRB2インターフェイスを送信してパケットを送信します。
Often, all the hosts in a particular Tenant Domain will be provisioned with the same value of the default router IP address. This IP address can be provisioned as an anycast address in all the EVPN PEs attached to that Tenant Domain. Thus, although all hosts are provisioned with the same default router address, the actual default router for a given host will be one of the PEs attached to the same Ethernet segment as the host. This provisioning method ensures that IP packets from a given host are handled by the closest EVPN PE that supports IRB.
多くの場合、特定のテナントドメインのすべてのホストは、デフォルトルーターIPアドレスの同じ値でプロビジョニングされます。このIPアドレスは、そのテナントドメインに添付されているすべてのEVPN PEのANYCASTアドレスとしてプロビジョニングできます。したがって、すべてのホストには同じデフォルトルーターアドレスでプロビジョニングされますが、特定のホストの実際のデフォルトルーターは、ホストと同じイーサネットセグメントに接続されたPEの1つになります。このプロビジョニング方法により、特定のホストからのIPパケットがIRBをサポートする最も近いEVPN PEによって処理されることが保証されます。
In the topology of Figure 4, one could imagine that H1 is configured with a default router address that belongs to PE2 but not to PE1. Inter-subnet routing would still work, but IP packets from H1 to H3 would then follow the non-optimal path H1-->PE1-->PE2-->PE1-->H3. Sending traffic on this sort of path, where it leaves a router and then comes back to the same router, is sometimes known as "hairpinning". Similarly, if PE2 supports IRB but PE1 dos not, the same non-optimal path from H1 to H3 would have to be followed. To avoid hairpinning, each EVPN PE needs to support IRB.
図4のトポロジでは、H1がPE2に属するがPE1に属するデフォルトのルーターアドレスで構成されていると想像できます。インターサブネットルーティングは引き続き機能しますが、H1からH3へのIPパケットは、非最適パスH1-> PE1-> PE2-> PE1-> H3に従います。この種のパスでトラフィックを送信し、ルーターを離れてから同じルーターに戻ることは、「ヘアピニング」として知られています。同様に、PE2がIRBをサポートしているが、PE1 DOSがサポートしていない場合、H1からH3への同じ非最適パスに従う必要があります。ヘアピニングを避けるために、各EVPN PEはIRBをサポートする必要があります。
It is worth pointing out the way IRB interfaces interact with multicast traffic. Referring again to Figure 4, suppose PE1 and PE2 are functioning as IP multicast routers. Also, suppose that H3 transmits a multicast packet and both H1 and H4 are interested in receiving that packet. PE1 will receive the packet from H3 via its IRB2 interface. The Ethernet encapsulation from BD2 is removed, the IP header processing is done, and the packet is then re-encapsulated for BD1, with PE1's MAC address in the MAC Source Address field. Then, the packet is sent down the IRB1 interface. Layer 2 procedures (as defined in [RFC7432]) would then be used to deliver a copy of the packet locally to H1 and remotely to H4.
IRBインターフェイスがマルチキャストトラフィックと対話する方法を指摘する価値があります。図4を再度参照すると、PE1とPE2がIPマルチキャストルーターとして機能していると仮定します。また、H3がマルチキャストパケットを送信し、H1とH4の両方がそのパケットの受信に関心があると仮定します。PE1は、IRB2インターフェイスを介してH3からパケットを受信します。BD2からのイーサネットのカプセル化が削除され、IPヘッダー処理が実行され、PE1のMACアドレスがMACソースアドレスフィールドにBD1に対して再エンコールされます。次に、パケットがIRB1インターフェイスから送信されます。レイヤー2の手順（[RFC7432]で定義されている）を使用して、パケットのコピーをローカルにH1に、リモートでH4に配信します。
Please be aware that this document modifies the semantics, described in the previous paragraph, of sending/receiving multicast traffic on an IRB interface. This is explained in Section 1.5.1 and subsequent sections.
このドキュメントは、IRBインターフェイスにマルチキャストトラフィックを送信/受信するという前の段落で説明されているセマンティクスを変更していることに注意してください。これについては、セクション1.5.1および後続のセクションで説明します。
The authors thank Vikram Nagarajan and Princy Elizabeth for their work on Sections 6.2 and 3.2.3.1. The authors also benefited tremendously from discussions with Aldrin Isaac on EVPN multicast optimizations.
著者は、セクション6.2および3.2.3.1での作業について、Vikram Nagarajanと王女エリザベスに感謝します。著者はまた、EVPNマルチキャストの最適化に関するAldrin Isaacとの議論から大きな恩恵を受けました。
Wen Lin
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: wlin@juniper.net
Zhaohui Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: zzhang@juniper.net
John Drake
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: jdrake@juniper.net
Eric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: erosen52@gmail.com
Jorge Rabadan
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Ali Sajassi
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com