Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9572 W. Lin
Updates: 7432 Juniper Networks
Category: Standards Track J. Rabadan
ISSN: 2070-1721 Nokia
K. Patel
Arrcus
A. Sajassi
Cisco Systems
May 2024
This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432.
このドキュメントは、プロバイダートンネルの選択的マルチキャストとセグメンテーションを含む、イーサネットVPN（EVPN）の放送、不明なユニキャスト、またはマルチキャスト（Bum）トラフィックを処理するための更新された手順を指定します。このドキュメントは、RFC 7432を更新します。
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/rfc9572.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9572で取得できます。
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. Requirements Language
1.2. Terminology
2. Tunnel Segmentation
2.1. Reasons for Tunnel Segmentation
3. Additional Route Types of EVPN NLRI
3.1. Per-Region I-PMSI A-D Route
3.2. S-PMSI A-D Route
3.3. Leaf A-D Route
4. Selective Multicast
5. Inter-AS Segmentation
5.1. Differences from Section 7.2.2 of RFC 7117 when Applied to
EVPNs
5.2. I-PMSI Leaf Tracking
5.3. Backward Compatibility
5.3.1. Designated ASBR Election
6. Inter-Region Segmentation
6.1. Area/AS vs. Region
6.2. Per-Region Aggregation
6.3. Use of S-NH-EC
6.4. Ingress PE's I-PMSI Leaf Tracking
7. Multihoming Support
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[RFC7117] specifies procedures for multicast in the Virtual Private LAN Service (VPLS multicast), using both inclusive tunnels and selective tunnels with or without inter-AS segmentation, similar to the Multicast VPN (MVPN) procedures specified in [RFC6513] and [RFC6514]. [RFC7524] specifies inter-area tunnel segmentation procedures for both VPLS multicast and MVPNs.
[RFC7117]は、仮想プライベートLANサービス（VPLSマルチキャスト）のマルチキャストの手順を指定します。]。[RFC7524]は、VPLSマルチキャストとMVPNの両方のエリア間トンネルセグメンテーション手順を指定します。
[RFC7432] specifies BGP MPLS-based Ethernet VPN (EVPN) procedures, including those handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic. [RFC7432] refers to [RFC7117] for details but leaves a few feature gaps related to selective tunnel and tunnel segmentation (Section 2.1).
[RFC7432]は、ブロードキャスト、不明なユニキャスト、またはマルチキャスト（BUM）トラフィックを含むBGP MPLSベースのイーサネットVPN（EVPN）手順を指定します。[RFC7432]は詳細については[RFC7117]を指しますが、選択的トンネルとトンネルのセグメンテーションに関連するいくつかの特徴ギャップを残します（セクション2.1）。
This document aims to fill in those gaps by covering the use of selective and segmented tunnels in EVPNs. In the same way that [RFC7432] refers to [RFC7117] for details, this document only specifies differences from relevant procedures provided in [RFC7117] and [RFC7524], rather than repeating the text from those documents. Note that these differences are applicable to EVPNs only and are not updates to [RFC7117] or [RFC7524].
このドキュメントは、EVPNでの選択的およびセグメント化されたトンネルの使用をカバーすることにより、これらのギャップを埋めることを目的としています。[RFC7432]が[RFC7117]を詳細に参照するのと同じように、このドキュメントは、これらのドキュメントからテキストを繰り返すのではなく、[RFC7117]および[RFC7524]で提供される関連手順との違いのみを指定します。これらの違いはEVPNのみに適用され、[RFC7117]または[RFC7524]の更新ではないことに注意してください。
MVPN, VPLS, and EVPN technologies all need to discover other Provider Edges (PEs) in the same L3/L2 VPN and announce the inclusive tunnels. MVPN technology introduced the Inclusive P-Multicast Service Interface (I-PMSI) concept and uses I-PMSI Auto-Discovery (A-D) routes for that purpose. EVPN technology uses Inclusive Multicast Ethernet Tag (IMET) A-D routes, but VPLS technology just adds a PMSI Tunnel Attribute (PTA) to an existing VPLS A-D route for that purpose. For selective tunnels, they all do use the same term: Selective PMSI (S-PMSI) A-D routes.
MVPN、VPLS、およびEVPNテクノロジーはすべて、同じL3/L2 VPNで他のプロバイダーエッジ（PE）を発見し、包括的なトンネルを発表する必要があります。MVPNテクノロジーは、Inclusive P-Multicast Service Interface（I-PMSI）コンセプトを導入し、その目的のためにI-PMSIオートディスコーブリ（A-D）ルートを使用しました。EVPNテクノロジーは、包括的なマルチキャストイーサネットタグ（IMET）A-Dルートを使用しますが、VPLSテクノロジーはPMSIトンネル属性（PTA）をその目的のために既存のVPLS A-Dルートに追加するだけです。選択的トンネルの場合、それらはすべて同じ用語を使用します：選択的PMSI（S-PMSI）A-Dルート。
This document often refers to the I-PMSI concept, which is the same for all three technologies. For consistency and convenience, an EVPN's IMET A-D route and a VPLS's VPLS A-D route carrying a PTA for BUM traffic purposes may each be referred to as an I-PMSI A-D route, depending on the context.
このドキュメントは、多くの場合、3つのテクノロジーすべてで同じI-PMSIコンセプトを指します。一貫性と利便性のために、EVPNのIMET A-Dルートと、バムトラフィックのためにPTAを運ぶVPLSのVPLS A-Dルートは、それぞれがコンテキストに応じてI-PMSI A-Dルートと呼ばれる場合があります。
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]で説明されているように解釈されます。
It is assumed that the reader is familiar with concepts and terminologies related to MVPN technology [RFC6513] [RFC6514], VPLS multicast [RFC7117], and EVPN technology [RFC7432]. For convenience, the following terms are briefly explained.
読者は、MVPNテクノロジー[RFC6513] [RFC6514]、VPLSマルチキャスト[RFC7117]、およびEVPNテクノロジー[RFC7432]に関連する概念と用語に精通していると想定されています。便宜上、次の用語を簡単に説明します。
AS:
AS:
Autonomous System
自律システム
PMSI [RFC6513]:
PMSI [RFC6513]：
P-Multicast Service Interface. A conceptual interface for a PE to send customer multicast traffic to all or some PEs in the same VPN.
P-Multicastサービスインターフェイス。同じVPNのすべてまたは一部のPEに顧客マルチキャストトラフィックを送信するためのPEの概念インターフェイス。
I-PMSI:
i-pmsi：
Inclusive PMSI. Enables traffic to be sent to all PEs in the same VPN.
包括的PMSI。同じVPNのすべてのPEにトラフィックを送信できるようにします。
S-PMSI:
S-PMSI：
Selective PMSI. Enables traffic to be sent to some of the PEs in the same VPN.
選択的PMSI。同じVPNのPESの一部にトラフィックを送信できるようにします。
I/S-PMSI A-D Route:
I/S-PMSI A-Dルート：
Auto-Discovery route used to announce the tunnels that instantiate an I/S-PMSI.
I/S-PMSIをインスタンス化するトンネルを発表するために使用される自動発見ルート。
Leaf Auto-Discovery (A-D) Route [RFC6513]:
リーフオートディスコーブリ（A-D）ルート[RFC6513]：
For explicit leaf-tracking purposes. Triggered by I/S-PMSI A-D routes and targeted at the triggering route's (re-)advertiser. Its Network Layer Reachability Information (NLRI) embeds the entire NLRI of the triggering PMSI A-D route.
明示的な葉の追跡のために。I/S-PMSI A-Dルートによってトリガーされ、トリガールートの（RE）広告主をターゲットにしました。そのネットワークレイヤーリーチ可能性情報（NLRI）は、PMSI A-DルートのトリガーのNLRI全体を埋め込みます。
IMET A-D Route [RFC7432]:
IMET A-Dルート[RFC7432]：
Inclusive Multicast Ethernet Tag A-D route. The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D route used to announce the tunnels that instantiate an I-PMSI.
包括的マルチキャストイーサネットタグA-Dルート。I-PMSIをインスタンス化するトンネルを発表するために使用されるI-PMSI A-DルートとしてのMVPN Intra-Intra-as AS Intra-as as Intra-as as as as as as as as as as as as as as intraに相当します。
SMET A-D Route [RFC9251]:
SMET A-Dルート[RFC9251]：
Selective Multicast Ethernet Tag A-D route. The EVPN equivalent of an MVPN Leaf A-D route, but unsolicited and untargeted.
選択的なマルチキャストイーサネットタグA-Dルート。MVPNリーフA-Dルートに相当するEVPN。
PMSI Tunnel Attribute (PTA):
PMSIトンネル属性（PTA）：
An optional transitive BGP attribute that may be attached to PMSI/Leaf A-D routes to provide information for a PMSI tunnel.
PMSI/LEAF A-Dルートに取り付けられて、PMSIトンネルの情報を提供する可能性のあるオプションの推移的BGP属性。
IBGP:
IBGP：
Internal BGP (BGP connection between internal peers).
内部BGP（内部ピア間のBGP接続）。
EBGP:
EBGP：
External BGP (BGP connection between external peers).
外部BGP（外部ピア間のBGP接続）。
RT:
RT:
Route Target. Controls route importation and propagation.
ルートターゲット。ルートのインポートと伝播を制御します。
MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are referred to as MVPN/EVPN/VPLS provider tunnels in this document for simplicity, can be segmented for technical or administrative reasons, which are summarized in Section 2.1 of this document. [RFC6513] and [RFC6514] cover MVPN inter-AS segmentation, [RFC7117] covers VPLS multicast inter-AS segmentation, and [RFC7524] (seamless MPLS multicast) covers inter-area segmentation for both MVPNs and VPLSs.
MVPNプロバイダートンネルおよびEVPN/VPLSバムプロバイダートンネルは、このドキュメントのMVPN/EVPN/VPLSプロバイダートンネルと呼ばれ、このドキュメントのセクション2.1に要約されている技術的または管理上の理由でセグメント化できます。[RFC6513]および[RFC6514]は、MVPN間のセグメンテーションをカバーし、[RFC7117]はVPLSマルチキャスト間ASセグメンテーション、および[RFC7524]（Seamless MPLS Multicast）をカバーします。
With tunnel segmentation, different segments of an end-to-end tunnel may have different encapsulation overheads. However, the largest overhead of the tunnel caused by an encapsulation method on a particular segment is not different from the case of a non-segmented tunnel with that encapsulation method. This is similar to the case of a network with different link types.
トンネルセグメンテーションにより、エンドツーエンドトンネルの異なるセグメントには、異なるカプセル化オーバーヘッドがある場合があります。ただし、特定のセグメントのカプセル化方法によって引き起こされるトンネルの最大のオーバーヘッドは、そのカプセル化方法を備えた非セグメントトンネルの場合と違いはありません。これは、リンクタイプが異なるネットワークの場合に似ています。
There is a difference between MVPN and VPLS multicast inter-AS segmentation (the VPLS approach is briefly described in Section 5.1). For simplicity, EVPNs will use the same procedures as those for MVPNs. All ASBRs can re-advertise their choice of the best route. Each can become the root of its intra-AS segment and inject traffic it receives from its upstream, while each downstream PE/ASBR will only pick one of the upstream ASBRs as its upstream. This is also the behavior even for VPLS in the case of inter-area segmentation.
MVPNとVPLSマルチキャストInter-ASセグメンテーションには違いがあります（VPLSアプローチについては、セクション5.1で簡単に説明します）。簡単にするために、EVPNはMVPNSの手順と同じ手順を使用します。すべてのASBRは、最適なルートの選択を再承認できます。それぞれがそのセグメント内のルートになり、上流から受信するトラフィックを注入することができますが、各下流のPE/ASBRは上流のASBRの1つのみを選択します。これは、エリア間セグメンテーションの場合のVPLでも動作です。
For inter-area segmentation, [RFC7524] requires the use of the Inter-Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community (S-NH-EC) and the setting of the Leaf Information Required (L) flag in the PTA in certain situations. In the EVPN case, the requirements around the S-NH-EC and the L flag in the PTA differ from [RFC7524] to make the segmentation procedures transparent to ingress and egress PEs.
エリア間セグメンテーションのために、[RFC7524]では、エリア間ポイントツーマルチポイント（P2MP）セグメント化されたネクストホップ拡張コミュニティ（S-NH-EC）と必要な葉情報の設定（L）フラグを使用する必要があります。特定の状況でPTAで。EVPNの場合、S-NH-ECとPTAのLフラグをめぐる要件は[RFC7524]とは異なり、セグメンテーション手順を透過と出力PESに透明にします。
[RFC7524] assumes that segmentation happens at area borders. However, it could be at "regional" borders, where a region could be a sub-area, or even an entire AS plus its external links (Section 6.1); this would allow for more flexible deployment scenarios (e.g., for single-area provider networks). This document extends the inter-area segmentation concept to inter-region segmentation for EVPNs.
[RFC7524]は、地域の境界でセグメンテーションが発生すると仮定しています。ただし、地域がサブエリアである可能性がある「地域の」国境にある可能性があります。これにより、より柔軟な展開シナリオが可能になります（単一エリアプロバイダーネットワークの場合）。このドキュメントは、エリア間セグメンテーションの概念をEVPNの地域間セグメンテーションに拡張します。
Tunnel segmentation may be required and/or desired for administrative and/or technical reasons.
トンネルセグメンテーションは、管理上および/または技術的な理由で必要および/または望まれる場合があります。
For example, an MVPN/VPLS/EVPN may span multiple providers, and the end-to-end provider tunnels have to be segmented at and stitched by the ASBRs. Different providers may use different tunnel technologies (e.g., provider A uses ingress replication [RFC7988], provider B uses RSVP-TE P2MP [RFC4875], and provider C uses Multipoint LDP (mLDP) [RFC6388]). Even if they use the same tunnel technology (e.g., RSVP-TE P2MP), it may be impractical to set up the tunnels across provider boundaries.
たとえば、MVPN/VPLS/EVPNは複数のプロバイダーにまたがる場合があり、エンドツーエンドのプロバイダートンネルをASBRSでセグメント化し、縫い付ける必要があります。異なるプロバイダーは、異なるトンネルテクノロジーを使用する場合があります（例：プロバイダーAはイングレスレプリケーション[RFC7988]を使用し、プロバイダーBはRSVP-TE P2MP [RFC4875]を使用し、プロバイダーCはマルチポイントLDP（MLDP）[RFC6388]を使用します。同じトンネルテクノロジー（RSVP-TE P2MPなど）を使用している場合でも、プロバイダーの境界にトンネルをセットアップすることは実用的ではない場合があります。
The same situations may apply between the ASes and/or areas of a single provider. For example, the backbone area may use RSVP-TE P2MP tunnels while non-backbone areas may use mLDP tunnels.
ASESおよび/または単一のプロバイダーの領域の間に同じ状況が適用される場合があります。たとえば、バックボーン領域はRSVP-TE P2MPトンネルを使用し、非骨骨エリアではMLDPトンネルを使用する場合があります。
Segmentation can also be used to divide an AS/area into smaller regions, so that control plane state and/or forwarding plane state/ burden can be limited to that of individual regions. For example, instead of ingress-replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524], a PE only needs to replicate to local PEs and Area Border Routers (ABRs). The ABRs will further replicate to their downstream PEs and ABRs. This not only reduces the forwarding plane burden, but also reduces the leaf-tracking burden in the control plane.
セグメンテーションは、AS/エリアをより小さな領域に分割するために使用することもできます。そのため、コントロールプレーンの状態および/または転送面の状態/負担は、個々の領域のそれに限定できます。たとえば、AS全体で100個のPEに侵入する代わりに、エリア間セグメンテーション[RFC7524]を使用して、PEはローカルPEと面積ボーダールーター（ABR）に複製するだけです。ABRは、下流のPESおよびABRにさらに複製します。これにより、転送面の負担が軽減されるだけでなく、コントロールプレーンの葉を追跡する負担を軽減します。
In the case of tunnel aggregation, smaller regions provide the benefit of making it easier to find congruence among the segments of different constituent (service) tunnels and the resulting aggregation (base) tunnel in a region. This leads to better bandwidth efficiency, because the more congruent they are, the fewer leaves of the base tunnel need to discard traffic when a service tunnel's segment does not need to receive the traffic (yet it is receiving the traffic due to aggregation).
トンネルの凝集の場合、小さい領域は、異なる成分（サービス）トンネルのセグメントと、地域の結果として得られる集約（ベース）トンネルのセグメント間の一致を容易にすることの利点を提供します。これにより、帯域幅の効率が向上します。なぜなら、それらがより一致するほど、サービストンネルのセグメントがトラフィックを受信する必要がない場合に、ベーストンネルの葉がトラフィックを廃棄する必要が少ないためです（まだ集約によりトラフィックを受け取っています）。
Another advantage of the smaller region is smaller Bit Index Explicit Replication (BIER) subdomains [RFC8279]. With BIER, packets carry a BitString, in which the bits correspond to edge routers that need to receive traffic. Smaller subdomains means that smaller BitStrings can be used without having to send multiple copies of the same packet.
小さい領域のもう1つの利点は、より小さなビットインデックス明示的複製（BIER）サブドメイン[RFC8279]です。Bierを使用すると、パケットにはビットストリングがあり、ビットはトラフィックを受信する必要があるエッジルーターに対応します。より小さなサブドメインは、同じパケットの複数のコピーを送信することなく、より小さなビットストリングを使用できることを意味します。
[RFC7432] defines the format of EVPN NLRI as follows:
[RFC7432] EVPN NLRIの形式を次のように定義します。
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
So far, eight route types have been defined in [RFC7432], [RFC9136], and [RFC9251]:
これまでのところ、[RFC7432]、[RFC9136]、および[RFC9251]で8つのルートタイプが定義されています。
+=======+=========================================+
| Value | Description |
+=======+=========================================+
| 1 | Ethernet Auto-discovery |
+-------+-----------------------------------------+
| 2 | MAC/IP Advertisement |
+-------+-----------------------------------------+
| 3 | Inclusive Multicast Ethernet Tag |
+-------+-----------------------------------------+
| 4 | Ethernet Segment |
+-------+-----------------------------------------+
| 5 | IP Prefix |
+-------+-----------------------------------------+
| 6 | Selective Multicast Ethernet Tag Route |
+-------+-----------------------------------------+
| 7 | Multicast Membership Report Synch Route |
+-------+-----------------------------------------+
| 8 | Multicast Leave Synch Route |
+-------+-----------------------------------------+
Table 1: Pre-existing Route Types
表1：既存のルートタイプ
This document defines three additional route types:
このドキュメントでは、3つの追加ルートタイプを定義します。
+=======+=============================+
| Value | Description |
+=======+=============================+
| 9 | Per-Region I-PMSI A-D route |
+-------+-----------------------------+
| 10 | S-PMSI A-D route |
+-------+-----------------------------+
| 11 | Leaf A-D route |
+-------+-----------------------------+
Table 2: New Route Types
表2：新しいルートタイプ
The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-field MUST match that of the RD in all current EVPN routes that are not Leaf A-D routes (Section 3.3), i.e., non-Leaf A-D routes from the same advertising router for a given EVPN instance (EVI).
タイプ9とタイプ10 EVPN NLRISの「ルートタイプ固有の」フィールドは、タイプ1 RD（ルートdistiutiuseer）で始まります。セクション3.3）、つまり、特定のEVPNインスタンス（EVI）の同じ広告ルーターからの非葉A-Dルート。
The per-region I-PMSI A-D route has the following format. Its usage is discussed in Section 6.2.
領域ごとのI-PMSI A-Dルートには、次の形式があります。その使用法については、セクション6.2で説明します。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------+
| Region ID (8 octets) |
+-----------------------------------+
The Region ID identifies the region and is encoded in the same way that an EC is encoded, as detailed in Section 6.2.
領域IDは、領域を識別し、セクション6.2で詳述されているように、ECがエンコードされるのと同じ方法でエンコードされます。
The S-PMSI A-D route has the following format:
S-PMSI A-Dルートには次の形式があります。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (variable) |
+-----------------------------------+
|Originator's Addr Length (1 octet) |
+-----------------------------------+
|Originator's Addr (4 or 16 octets) |
+-----------------------------------+
Other than the addition of the Ethernet Tag ID and Originator's Addr Length fields, it is identical to the S-PMSI A-D route as defined in [RFC7117]. The procedures specified in [RFC7117] also apply (including wildcard functionality), except that the granularity level is per Ethernet Tag.
イーサネットタグIDとオリジネーターのADDR長さフィールドの追加を除き、[RFC7117]で定義されているS-PMSI A-Dルートと同じです。[RFC7117]で指定されている手順は、粒度レベルがイーサネットタグごとであることを除いて、適用されます（ワイルドカード機能を含む）。
The Route Type specific field of a Leaf A-D route consists of the following:
リーフA-N-Dルートのルートタイプ固有フィールドは、次のもので構成されています。
+-----------------------------------+
| Route Key (variable) |
+-----------------------------------+
|Originator's Addr Length (1 octet) |
+-----------------------------------+
|Originator's Addr (4 or 16 octets) |
+-----------------------------------+
A Leaf A-D route is originated in response to a PMSI route, which could be an IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future that trigger Leaf A-D routes. The Route Key is the NLRI of the route for which this Leaf A-D route is generated.
Leaf A-Dルートは、IMET A-Dルート、領域ごとのI-PMSI A-Dルート、S-PMSI A-Dルート、またはその他のタイプのルートであるPMSIルートに応答して発生します。リーフA-Dルートをトリガーする未来。ルートキーは、このリーフA-Dルートが生成されるルートのNLRIです。
The general procedures for Leaf A-D routes were first specified in [RFC6514] for MVPNs. The principles therein apply to VPLSs and EVPNs as well. [RFC7117] provides details regarding VPLS multicast, and this document points out some specifics for EVPNs, e.g., in Section 5.
葉のA-Dルートの一般的な手順は、MVPNの[RFC6514]で最初に指定されました。その原則は、VPLSとEVPNにも適用されます。[RFC7117]はVPLSマルチキャストに関する詳細を提供し、このドキュメントでは、EVPNのいくつかの詳細を示しています。
[RFC9251] specifies procedures for EVPN selective forwarding of IP multicast traffic using SMET routes. It assumes that selective forwarding is always used with ingress replication for all flows (though the same signaling can also be used for an ingress PE to learn the set of egress PEs for selective forwarding with BIER). A Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD" stands for "Multicast Listener Discovery") that it learns on its Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that are advertised to other NVEs, and a receiving NVE converts the SMET routes back to IGMP/MLD messages and sends them out of its ACs. The receiving NVE also uses the SMET routes to identify which NVEs need to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using ingress replication or BIER.
[RFC9251]は、SMETルートを使用したIPマルチキャストトラフィックのEVPN選択転送の手順を指定します。選択的転送は、すべてのフローのイングレスレプリケーションで常に使用されると仮定します（ただし、同じシグナルを入力PEに使用して、ビアを使用して選択的な転送のために出力PEのセットを学習することもできます）。ネットワーク仮想化エッジ（NVE）は、IGMP/MLD状態（「MLD」は「マルチキャストリスナーディスカバリー」を表す）をプロキシします。他のNVEに宣伝され、受信したNVEはSMETルートをIGMP/MLDメッセージに変換し、ACSから送信します。また、受信NVEは、SMETルートを使用して、特定の（C-S、C-G）または（C-*、C-G）のトラフィックを受信する必要があるNVEを特定して、イングレスレプリケーションまたはビアを使用して選択的転送を実現します。
With the above procedures, selective forwarding is done for all flows, and the SMET routes are advertised for all flows. It is possible that an operator may not want to track all those (C-S, C-G) or (C-*,C-G) states on the NVEs, and the multicast traffic pattern allows inclusive forwarding for most flows while selective forwarding is needed only for a few high-rate flows. For that reason, or for tunnel types other than ingress replication or BIER, S-PMSI/Leaf A-D procedures defined for selective multicast for VPLS in [RFC7117] are used. Other than the fact that different route types and formats are specified with an EVPN SAFI for S-PMSI A-D and Leaf A-D routes (Section 3), all procedures specified in [RFC7117] with respect to selective multicast apply to EVPNs as well, including wildcard procedures. In a nutshell, a source NVE advertises S-PMSI A-D routes to announce the tunnels used for certain flows, and receiving NVEs either join the announced PIM/mLDP tunnel or respond with Leaf A-D routes if the L flag is set in the S-PMSI A-D route's PTA (so that the source NVE can include them as tunnel leaves).
上記の手順では、すべてのフローに対して選択的転送が行われ、すべてのフローに対してSMETルートが宣伝されます。オペレーターは、NVE上のすべての（C-S、C-G）または（C-*、C-G）状態をすべて追跡したくない場合があり、マルチキャストトラフィックパターンはほとんどのフローの包括的転送を可能にしますが、選択的転送が必要です。高速のフローはほとんどありません。そのため、またはイングレスレプリケーションまたはビア以外のトンネルタイプの場合、[RFC7117]のVPLの選択的マルチキストに対して定義されたS-PMSI/LEAF A-D手順を使用します。S-PMSI A-DおよびLeaf A-DルートのEVPN SAFI（セクション3）で異なるルートタイプとフォーマットが指定されているという事実以外に、[RFC7117]に関して[RFC7117]で指定されたすべての手順も、WildCardを含むEVPNに適用されます。手順。一言で言えば、ソースNVEはS-PMSI A-Dルートを宣伝して特定のフローに使用されるトンネルを発表し、NVEを受信して、発表されたPIM/MLDPトンネルに参加するか、LフラグがS-PMSIに設定されている場合はLeaf A-Dルートで応答しますA-DルートのPTA（ソースNVEがトンネルの葉としてそれらを含めることができるように）。
An optimization to the procedures provided in [RFC7117] may be applied. Even if a source NVE sets the L flag to request Leaf A-D routes, an egress NVE MAY omit the Leaf A-D route if it has already advertised a corresponding SMET route, and the source NVE MUST use that in lieu of the Leaf A-D route.
[RFC7117]で提供される手順の最適化を適用できます。ソースNVEがLフラグを設定してLeaf A-Dルートを要求した場合でも、脱出したNVEは、対応するSMETルートを既に宣伝している場合、Leaf A-Dルートを省略する場合があり、ソースNVEはLeaf A-Dルートの代わりにそれを使用する必要があります。
The optional optimizations specified for MVPNs in [RFC8534] are also applicable to EVPNs when the procedures for S-PMSI/Leaf A-D routes are used for EVPN selective multicast forwarding.
[RFC8534]のMVPNに指定されたオプションの最適化は、S-PMSI/LEAF A-Dルートの手順がEVPN選択的マルチキャスト転送に使用される場合にもEVPNに適用できます。
The first paragraph of Section 7.2.2.2 of [RFC7117] says:
[RFC7117]のセクション7.2.2.2の最初の段落には次のように書かれています。
... The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP). This ASBR becomes the root of the intra-AS segment of the inter-AS tree and ensures that this is the only ASBR that accepts traffic into this AS from the inter-AS tree.
...最良のルート手順により、ASで複数のASBRがEBGPの隣人から同じA-D-D-Dルートを受け取る場合、これらのASBRの1つだけが内部BGP（IBGP）でこのルートを伝播することを保証します。このASBRは、AS Inter-ASツリーのAS ASセグメントの根のルートになり、これがThe Inter-ASツリーからこれへのトラフィックを受け入れる唯一のASBRであることを保証します。
The above VPLS behavior requires complicated VPLS-specific procedures for the ASBRs to reach agreement. For EVPNs, a different approach is used; the above text from [RFC7117] is not applicable to EVPNs.
上記のVPLS動作には、ASBRが合意に達するために複雑なVPLS固有の手順が必要です。EVPNの場合、別のアプローチが使用されます。[RFC7117]の上記のテキストは、EVPNには適用されません。
With the different approach for EVPNs/MVPNs, each ASBR will re-advertise its received Inter-AS A-D route to its IBGP peers and becomes the root of an intra-AS segment of the inter-AS tree. The intra-AS segment rooted at one ASBR is disjoint from another intra-AS segment rooted at another ASBR. This is the same as the procedures for S-PMSI routes in [RFC7117] itself.
EVPNS/MVPNSのさまざまなアプローチにより、各ASBRは、受け取ったAS Inter-DルートをIBGPピアへのA-Dルートを再承認し、AS Inter-ASツリーのAS ASセグメントのルートになります。あるASBRに根ざしたASのASセグメントは、別のASBRに根付いた別のAS ASセグメントからのばらばらです。これは、[RFC7117]自体のS-PMSIルートの手順と同じです。
The following bullet in Section 7.2.2.2 of [RFC7117] does not apply to EVPNs.
[RFC7117]のセクション7.2.2.2の次の弾丸は、EVPNには適用されません。
* If the ASBR uses ingress replication to instantiate the intra-AS segment of the inter-AS tunnel, the re-advertised route MUST NOT carry the PMSI Tunnel attribute.
* ASBRがIngressレプリケーションを使用して、AS間のトンネル間のASセグメント内をインスタンス化する場合、再承認されたルートはPMSIトンネル属性を運んではなりません。
The following bullet in Section 7.2.2.2 of [RFC7117]:
[RFC7117]のセクション7.2.2.2の次の弾丸：
* If the ASBR uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree that is used to instantiate the segment (note that the ASBR could create the identity of the tree prior to the actual instantiation of the segment). If, in order to instantiate the segment, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the A-D routes received from other PEs/ASBRs in the ASBR's own AS.
* ASBRがP-Multicastツリーを使用してAS Inter-ASトンネルのセグメント内をインスタンス化する場合、PMSIトンネル属性にはセグメントをインスタンス化するために使用されるツリーのIDを含める必要があります（ASBRはIDを作成できることに注意してくださいセグメントの実際のインスタンス化前のツリーの）。セグメントをインスタンス化するために、ASBRがツリーの葉を知る必要がある場合、ASBRはASBRのASの他のPES/ASBRから受け取ったA-Dルートからこの情報を取得します。
is changed to the following when applied to EVPNs:
EVPNに適用されると、次のように変更されます。
* The PTA MUST specify the tunnel for the segment. If and only if, in order to establish the tunnel, the ASBR needs to know the leaves of the tree, then the ASBR MUST set the L flag to 1 in the PTA to trigger Leaf A-D routes from egress PEs and downstream ASBRs. It MUST be (auto-)configured with an import RT, which controls acceptance of Leaf A-D routes by the ASBR.
* PTAは、セグメントのトンネルを指定する必要があります。トンネルを確立するために、ASBRが木の葉を知る必要がある場合にのみ、ASBRは、出力PESおよび下流のASBRから葉のA-DルートをトリガーするためにPTAのLフラグを1に設定する必要があります。ASBRによるリーフA-Dルートの受け入れを制御するインポートRTで（自動）構成する必要があります。
Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:
したがって、[RFC7117]のセクション7.2.2.4の次の段落：
If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSP MAY have been established before the local PE/ASBR receives the route, or it MAY be established after the local PE receives the route.
受信したAS Inter AS A-Dルートが、RSVP-TE P2MP LSPに設定されたトンネル識別子を使用してPMSIトンネル属性を搭載している場合、ルートを発信したASBRは、ローカルPE/ASBRを葉としてRSVP-TE P2MP LSPを確立する必要があります。このLSPは、ローカルPE/ASBRがルートを受信する前に確立された可能性があります。または、ローカルPEがルートを受け取った後に確立される場合があります。
is changed to the following when applied to EVPNs:
EVPNに適用されると、次のように変更されます。
If the received Inter-AS A-D route has the L flag set in its PTA, then a receiving PE MUST originate a corresponding Leaf A-D route. A receiving ASBR MUST originate a corresponding Leaf A-D route if and only if one of the following conditions is met: (1) it received and imported one or more corresponding Leaf A-D routes from its downstream IBGP or EBGP peers or (2) it has non-null downstream forwarding state for the PIM/mLDP tunnel that instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route, which (re-)advertised the Inter-AS A-D route, MUST establish a tunnel to the leaves discovered by the Leaf A-D routes.
受信したAS Inter AS A-DルートのPTAにLフラグが設定されている場合、受信PEは対応するリーフA-Dルートを発生する必要があります。受信ASBRは、次の条件のいずれかが満たされている場合にのみ、対応するリーフA-Dルートを発生する必要があります。（1）下流のIBGPまたはEBGPピアから1つまたは複数の対応するリーフA-Dルートを受信およびインポートするか、（2）非存在-Down Stream Forwarding Stateは、下流のASセグメントをインスタンス化するPIM/MLDPトンネルの状態です。葉のA-Dルートを宣伝したLeaf A-DルートのターゲットASBRは、Leaf A-Dルートによって発見された葉へのトンネルを確立する必要があります。
An ingress PE does not set the L flag in its IMET A-D route's PTA, even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 of [RFC7432] explicitly states that the L flag must be set to 0.
侵入PEは、侵入レプリケーショントンネルまたはRSVP-TE P2MPトンネルでも、IMET A-DルートのPTAにLフラグを設定しません。[RFC7432]のセクション11.2は、Lフラグを0に設定する必要があることを明示的に述べています。
An implementation of [RFC7432] might have used the Originating Router's IP Address field of the IMET A-D routes to determine the leaves or might have used the Next Hop field instead. Within the same AS, both will lead to the same result.
[RFC7432]の実装により、IMET A-Dルートの元のルーターのIPアドレスフィールドを使用して葉を決定するか、代わりに次のホップフィールドを使用した可能性があります。同じように、両方とも同じ結果につながります。
With segmentation, an ingress PE MUST determine the leaves in its AS from the BGP next hops in all its received IMET A-D routes, so it does not have to set the L flag to request Leaf A-D routes. PEs within the same AS will all have different next hops in their IMET A-D routes (and hence will all be considered as leaves), and PEs from other ASes will have the next hop in their IMET A-D routes set to addresses of ASBRs in this local AS; hence, only those ASBRs will be considered as leaves (as proxies for those PEs in other ASes). Note that in the case of ingress replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those routes for the same Ethernet Tag ID and the same EVI. Otherwise, duplicated copies will be sent by the ingress PE and received by egress PEs in other regions. For the same reason, when an ingress PE builds its flooding list, if multiple routes have the same (nexthop, label) tuple, they MUST only be added as a single branch in the flooding list.
セグメンテーションを使用すると、侵入PEは、受信したすべてのIMET A-DルートでBGPの次のホップからASの葉を決定する必要があるため、Lフラグを設定してLeaf A-Dルートを要求する必要はありません。すべてがIMET A-Dルートに異なる次のホップを持っているのと同じ内のPES（したがって、すべて葉と見なされます）。として;したがって、それらのASBRのみが葉と見なされます（他のASEのPESのプロキシとして）。Ingress Replicationの場合、ASBRがIMET A-DルートをIBGPピアに再承認する場合、同じイーサネットタグIDと同じEVIのすべてのルートに対して同じラベルを宣伝する必要があることに注意してください。それ以外の場合、複製されたコピーは、イングレスPEによって送信され、他の地域の出力PESによって受信されます。同じ理由で、Ingress PEが洪水リストを構築する場合、複数のルートが同じ（Nexthop、Label）タプルを持っている場合、それらは洪水リストに単一のブランチとしてのみ追加する必要があります。
The above procedures assume that all PEs are upgraded to support the segmentation procedures:
上記の手順では、すべてのPEがセグメンテーション手順をサポートするためにアップグレードされていると想定しています。
* An ingress PE uses the Next Hop and not the Originating Router's IP Address to determine leaves for the I-PMSI tunnel.
* Ingress PEは、次のホップを使用しており、RouterのIPアドレスではなく、I-PMSIトンネルの葉を決定します。
* An egress PE sends Leaf A-D routes in response to I-PMSI routes, if the PTA has the L flag set by the re-advertising ASBR.
* PTAに再版ASBRによって設定されたLフラグがある場合、出力PEはI-PMSIルートに応答してLeaf A-Dルートを送信します。
* In the case of ingress replication, when an ingress PE builds its flooding list, multiple I-PMSI routes may have the same (nexthop, label) tuple, and only a single branch for those routes will be added in the flooding list.
* イングレスレプリケーションの場合、Ingress PEが洪水リストを構築すると、複数のI-PMSIルートが同じ（Nexthop、Label）タプルを持つ場合があり、それらのルートの単一のブランチのみが洪水リストに追加されます。
If a deployment has legacy PEs that do not support the above, then a legacy ingress PE would include all PEs (including those in remote ASes) as leaves of the inclusive tunnel and try to send traffic to them directly (no segmentation), which is either undesirable or impossible; a legacy egress PE would not send Leaf A-D routes so the ASBRs would not know to send external traffic to them.
展開には上記をサポートしていないレガシーPEがある場合、レガシーイングレスPEには、包括的トンネルの葉としてすべてのPE（リモートASESを含む）が含まれ、それらに直接トラフィックを送信しようとします（セグメンテーションなし）。望ましくない、または不可能のいずれか。レガシーの出口PEは、葉のA-Dルートを送信しないため、ASBRSは外部トラフィックを送信することを知りません。
If this backward-compatibility problem needs to be addressed, the following procedure MUST be used (see Section 6.2 for per-PE/AS/ region I-PMSI A-D routes):
この後方互換性の問題に対処する必要がある場合、次の手順を使用する必要があります（PE/ AS/領域I-PMSI A-Dルートのセクション6.2を参照）。
* An upgraded PE indicates in its per-PE I-PMSI A-D route that it supports the new procedures. This is done by setting a flag bit in the EVPN Multicast Flags Extended Community.
* アップグレードされたPEは、PEPE I-PMSI A-Dルートで新しい手順をサポートすることを示します。これは、EVPNマルチキャストフラグ拡張コミュニティにフラグビットを設定することによって行われます。
* All per-PE I-PMSI A-D routes are restricted to the local AS and not propagated to external peers.
* すべてのPE PE I-PMSI A-Dルートは、地元のASに制限されており、外部ピアに伝播されません。
* The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise them to their external peers to specify tunnels used to carry traffic from the local AS to other ASes. Depending on the types of tunnels being used, the L flag in the PTA may be set, in which case the downstream ASBRs and upgraded PEs will send Leaf A-D routes to pull traffic from their upstream ASBRs. In a particular downstream AS, one of the ASBRs is elected, based on the per-region I-PMSI A-D routes for a particular source AS, to send traffic from that source AS to legacy PEs in the downstream AS. The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, as selected by the ASBR from all the routes that it received over EBGP or IBGP sessions. The election procedure is described in Section 5.3.1.
* ASのASBRは、領域ごとのI-PMSI A-Dルートを起源とし、外部のピアに宣伝し、他のASESに関してローカルからのトラフィックを運ぶために使用されるトンネルを指定します。使用されているトンネルの種類に応じて、PTAのLフラグが設定される場合があります。その場合、下流のASBRとアップグレードされたPESは、上流のASBRからトラフィックを引き出すためにリーフA-Dルートを送信します。特定の下流のASでは、特定のソースの領域ごとのI-PMSI A-Dルートに基づいて、ASBRの1つが選出され、下流のレガシーPESに関してそのソースからトラフィックを送信します。トラフィックは、EBGPまたはIBGPセッションで受け取ったすべてのルートからASBRによって選択されているように、ソース用の最高の領域ごとのI-PMSI A-Dルートで発表されたトンネル上の選出されたASBRに到着します。選挙手続きについては、セクション5.3.1に記載されています。
* In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), which are learned either explicitly via Leaf A-D routes or implicitly via PIM Join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a regular IMET route) into the local AS and stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. Via this process, it gets traffic from local PEs and sends the traffic to other ASes via the tunnel announced in its per-region I-PMSI A-D route.
* ASBRがアクティブな下流レシーバー（PESおよびASBR）を持っている場合にのみ、侵入/アップストリームで、Leaf A-Dルートを介して明示的に学習されるか、PIM結合またはMLDPラベルマッピングを介して暗黙的に学習されます。-PMSI A-Dルート（つまり、通常のIMETルート）はローカルASに入り、PEごとのI-PMSIトンネルごとに領域ごとのI-PMSIトンネルに入ります。このプロセスを介して、ローカルPEからトラフィックを取得し、領域ごとのI-PMSI A-Dルートで発表されたトンネルを介して他のASEにトラフィックを送信します。
Note that even if there are no backward-compatibility issues, the use of per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed) and reducing the number of inter-AS tunnels.
後方互換性の問題がない場合でも、領域ごとのI-PMSI A-Dルートの使用は、ローカルASEにすべてのPE I-PMSI A-Dルートを維持し、ルートの洪水を大幅に削減することの利点を提供することに注意してください。対応するリーフA-Dルート（必要な場合）とトンネル間の数を減らします。
When an ASBR re-advertises a per-region I-PMSI A-D route into an AS in which a designated ASBR needs to be used to forward traffic to the legacy PEs in the AS, it MUST include a Designated Forwarder (DF) Election EC. The EC and its use are specified in [RFC8584]. The AC-DF bit in the DF Election EC MUST be cleared. If it is known that no legacy PEs exist in the AS, the ASBR MUST NOT include the EC and MUST remove the DF Election EC if one is carried in the per-region I-PMSI A-D routes that it receives. Note that this is done for each set of per-region I-PMSI A-D routes with the same NLRI.
ASBRが領域ごとのI-PMSI A-DルートをASに再承認した場合、指定されたASBRを使用してASのレガシーPESにトラフィックを転送する必要がある場合、指定されたフォワーダー（DF）選挙ECを含める必要があります。ECとその使用は[RFC8584]で指定されています。DF選挙ECのAC-DFビットをクリアする必要があります。ASにレガシーPEが存在しないことがわかっている場合、ASBRはECを含めてはなりません。これは、同じNLRIを持つ領域ごとのI-PMSI A-Dルートの各セットに対して行われることに注意してください。
Based on the procedures specified in [RFC8584], an election algorithm is determined according to the DF Election ECs carried in the set of per-region I-PMSI routes of the same NLRI re-advertised into the AS. The algorithm is then applied to a candidate list, which is the set of ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI carrying the DF Election EC.
[RFC8584]で指定された手順に基づいて、選挙アルゴリズムは、ASに再承認された同じNLRIの地域ごとのI-PMSIルートのセットで運ばれるDF選挙ECSに従って決定されます。次に、アルゴリズムは候補リストに適用されます。これは、DF選挙ECを運ぶ同じNLRIの地域ごとのI-PMSIルートを再承認したASBRのセットです。
[RFC7524] addresses MVPN/VPLS inter-area segmentation and does not explicitly cover EVPNs. However, if "area" is replaced by "region" and "ABR" is replaced by "RBR" (Regional Border Router), then everything still works and can be applied to EVPNs as well.
[RFC7524]は、MVPN/VPLSエリア間セグメンテーションに対処し、EVPNを明示的にカバーしていません。ただし、「エリア」が「領域」に置き換えられ、「ABR」が「RBR」（地域の境界ルーター）に置き換えられている場合、すべてが機能し、EVPNにも適用できます。
A region can be a sub-area, or it can be an entire AS, including its external links. Instead of automatically defining a region based on IGP areas, a region would be defined as a BGP peer group. In fact, even with a region definition based on an IGP area, a BGP peer group listing the PEs and ABRs in an area is still needed.
地域はサブエリアである場合があります。または、外部リンクを含むAS全体にすることもできます。IGPエリアに基づいて地域を自動的に定義する代わりに、領域はBGPピアグループとして定義されます。実際、IGP領域に基づいた領域定義があっても、領域にPESとABRをリストするBGPピアグループがまだ必要です。
Consider the following example diagram for inter-AS segmentation:
ASセグメンテーション間の次の例を考えてみましょう。
--------- ------ ---------
/ \ / \ / \
/ \ / \ / \
| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 |
\ / \ / \ /
\ / \ / \ /
--------- ------ ---------
AS 100 AS 200 AS 300
|-----------|--------|---------|--------|------------|
segment1 segment2 segment3 segment4 segment5
The inter-AS segmentation procedures specified so far ([RFC6513], [RFC6514], [RFC7117], and Section 5 of this document) require all ASBRs to be involved, and ingress replication is used between two ASBRs in different ASes.
これまでに指定されたAS間のセグメンテーション手順（[RFC6513]、[RFC6514]、[RFC7117]、およびこの文書のセクション5）は、すべてのASBRを関与させる必要があり、イングレス複製は異なるASの2つのASBRの間で使用されます。
In the above diagram, it's possible that ASBR1/4 does not support segmentation, and the provider tunnels in AS 100/300 can actually extend across the external link. In this case, the inter-region segmentation procedures can be used instead -- a region is the entire AS100 plus the ASBR1-ASBR2 link or the entire AS300 plus the ASBR3-ASBR4 link. ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core router with respect to provider tunnels.
上記の図では、ASBR1/4がセグメンテーションをサポートしていない可能性があり、AS 100/300のプロバイダートンネルは実際に外部リンク全体に拡張できます。この場合、代わりに地域間セグメンテーション手順を使用できます。領域はAS100とASBR1-ASBR2リンク全体またはASBR3-ASBR4リンク全体全体です。ASBR2/3はRBRSであり、ASBR1/4はプロバイダートンネルに関するトランジットコアルーターにすぎません。
As illustrated in the diagram below, ASBR2/3 will establish a multihop EBGP session, either with a Route Reflector (RR) or directly with PEs in the neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be processed by ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in its own AS. When ASBR3 re-advertises I/S-PMSI A-D routes into the neighboring AS 300, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in the neighboring region. Now, the segment is rooted at ASBR3 and extends across the external link to PEs.
以下の図に示されているように、ASBR2/3は、ルートリフレクター（RR）を備えたマルチホップEBGPセッションを確立します。Ingress PESからのI/S-PMSI A-Dルートは、ASBR1/4によって処理されません。ASBR2がルートをAS 200に再承認すると、次のホップを独自のアドレスに変更し、PTAを変更してトンネルタイプ/識別を独自のASで指定します。ASBR3がI/S-PMSI A-Dを隣接するAS 300に再版画すると、次のホップを独自のアドレスに変更し、PTAを変更して隣接する領域でトンネルタイプ/識別を指定します。これで、セグメントはASBR3に根付いており、外部リンクを横切ってPESに拡張します。
--------- ------ ---------
/ RR....\.mh-ebpg / \ mh-ebgp/....RR \
/ : \ `. / \ .' / : \
| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 |
\ / \ / \ /
\ / \ / \ /
--------- ------ ---------
AS 100 AS 200 AS 300
|-------------------|----------|---------------------|
segment 1 segment 2 segment 3
Notice that every I/S-PMSI route from each PE will be propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-D routes, depending on the types of tunnels used in each region. This may result in too many routes and corresponding tunnels. To address this concern, the I-PMSI routes from all PEs in an AS/region can be aggregated into a single I-PMSI route originated from the RBRs, and traffic from all those individual I-PMSI tunnels will be switched into the single I-PMSI tunnel. This is like the MVPN Inter-AS I-PMSI route originated by ASBRs.
各PEからのすべてのI/S-PMSIルートは、すべてのASEまたは領域全体で伝播されることに注意してください。また、各地域で使用されるトンネルの種類に応じて、対応する葉のA-Dルートをトリガーする場合があります。これにより、ルートや対応するトンネルが多すぎる場合があります。この懸念に対処するために、AS/領域のすべてのPEからのI-PMSIルートは、RBRから発信される単一のI-PMSIルートに集約でき、それらすべての個々のI-PMSIトンネルからのトラフィックは単一のIに切り替えられます-pmsiトンネル。これは、ASBRが発信するI-PMSIルートとしてのMVPN間のようなものです。
The MVPN Inter-AS I-PMSI A-D route can be better called a "per-AS I-PMSI A-D route", to be compared against the (per-PE) Intra-AS I-PMSI A-D routes originated by each PE. In this document, we will call it a "per-region I-PMSI A-D route" in cases where we want to apply aggregation at the regional level. The per-PE I-PMSI routes will not be propagated to other regions. If multiple RBRs are connected to a region, then each will advertise such a route, with the same Region ID and Ethernet Tag ID (Section 3.1). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route from all those re-advertised by the upstream RBRs and hence will only receive traffic injected by one of them.
MVPN Inter-AS I-PMSI A-Dルートは、「PE-PMSI A-Dルート」と呼ばれる方が適しています。これは、各PEが発信するI-PMSI A-Dルートとして（PE PER）INTRA-AS IPRA-AS IPRA-AS IPRA-AS IPRA-AS AS INTA-AS IPS-A-Dルートと比較できます。このドキュメントでは、地域レベルで集約を適用したい場合に、「地域ごとのI-PMSI A-Dルート」と呼びます。PE PER I-PMSIルートは、他の地域に伝播されません。複数のRBRが領域に接続されている場合、それぞれが同じリージョンIDとイーサネットタグID（セクション3.1）を使用して、そのようなルートを宣伝します。PEPE I-PMSI A-Dルートと同様に、下流領域のRBRS/PESはそれぞれ、上流のRBRによって再承認されたすべてのルートから最適なルートを選択し、したがって、それらの1つによって注入されたトラフィックのみを受け取ります。
MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they do for I-PMSI routes, because the number of PEs that will advertise S-PMSI routes for the same (S,G) or (*,G) is small. This is also the case for EVPNs, i.e., there are no per-region S-PMSI routes.
MVPNは、I-PMSIルートのように、すべてのPESからS-PMSIルートを集約しません。これは、同じ（s、g）または（*、g）のS-PMSIルートを宣伝するPEの数は小さい。これは、EVPNSの場合もあります。つまり、領域ごとのS-PMSIルートはありません。
Notice that per-region I-PMSI routes can also be used to address backward-compatibility issues, as discussed in Section 5.3.
セクション5.3で説明したように、領域ごとのI-PMSIルートを使用して、後方互換性の問題に対処することもできます。
The Region ID in the per-region I-PMSI route's NLRI is encoded like an EC. For example, the Region ID can encode an AS number or area ID in the following EC format:
領域ごとのI-PMSIルートのNLRIの領域IDは、ECのようにエンコードされています。たとえば、リージョンIDは、次のEC形式でAS番号またはエリアIDをエンコードできます。
* For a two-octet AS number, a Transitive Two-Octet AS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.
* 2オクテットのAS番号の場合、サブタイプ0x09（Source AS）の推移的な2オクテットのAS固有のEC、グローバル管理者サブフィールドはAS番号に設定され、ローカル管理者サブフィールドは0に設定されます。
* For a four-octet AS number, a Transitive Four-Octet AS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.
* 4オクテットの場合、サブタイプ0x09（Source AS）の推移的な4オクテットのAS固有のEC、グローバル管理者サブフィールドがAS番号に設定され、ローカル管理者サブフィールドが0に設定されています。
* For an area ID, a Transitive IPv4-Address-specific EC of any sub-type, with the Global Administrator sub-field set to the area ID and the Local Administrator sub-field set to 0.
* 領域IDの場合、サブタイプの推移的なIPv4-Address固有のECで、グローバル管理者サブフィールドがエリアIDに設定され、ローカル管理者サブフィールドが0に設定されています。
The use of other EC encodings MAY be allowed as long as they uniquely identify the region and the RBRs for the same region use the same Region ID.
他のECエンコーディングの使用は、同じ領域のRBRSが同じ領域IDを使用している領域とRBRSを一意に識別する限り許可される場合があります。
[RFC7524] specifies the use of the S-NH-EC because it does not allow ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D routes to downstream areas. That behavior is only to be consistent with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be changed when they're re-advertised by the segmenting ABRs for reasons specific to MVPNs. For EVPNs, it is perfectly fine to change the next hop when RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on the S-NH-EC. As a result, this document specifies that RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D routes and do not use the S-NH-EC. This provides the advantage that neither ingress PEs nor egress PEs need to understand/use the S-NH-EC, and a consistent procedure (based on BGP next hops) is used for both inter-AS and inter-region segmentation.
[RFC7524]は、I/S-PMSI A-Dルートを下流領域に再編成するときにABRがBGPの次のホップを変更することを許可しないため、S-NH-ECの使用を指定します。その動作は、MVPNに固有の理由でABRをセグメント化することによって再承認されたときに次のホップを変更する必要はありません。EVPNSの場合、RBRSがS-NH-ECに依存するのではなく、I/S-PMSI A-Dルートを再承認するときに次のホップを変更することはまったく問題ありません。その結果、このドキュメントでは、RBRSがI/S-PMSI A-Dルートを再入力し、S-NH-ECを使用しないときにBGPの次のホップを変更することを指定します。これにより、侵入ペスも出口PESもS-NH-ECを理解/使用する必要がないという利点が得られ、AS間および地域間セグメンテーションの両方に一貫した手順（BGP Next Hopsに基づく）が使用されます。
If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received I/S-PMSI A-D route in the Global Administrator field of the extended community, with the Local Administrator field of this extended community set to 0, and also setting the Extended Communities attribute of the Leaf A-D route to that extended community.
下流のPE/RBRがリーフA-Dルートを発信する必要がある場合、IPベースのルートターゲット拡張コミュニティを構築します。この拡張コミュニティのローカル管理者フィールドが0に設定されており、また、その拡張コミュニティにリーフA-Dルートの拡張コミュニティ属性を設定した拡張コミュニティ。
Similar to [RFC7524], the upstream RBR MUST (auto-)configure an RT with the Global Administrator field set to the Next Hop in the re-advertised I/S-PMSI A-D route and with the Local Administrator field set to 0. Using this technique, the mechanisms specified in [RFC4684] for constrained BGP route distribution can be used along with this specification to ensure that only the needed PE/ABR will have to process a particular Leaf A-D route.
[RFC7524]と同様に、上流のRBRは、再承認されたI/S-PMSI A-Dルートの次のホップに設定されたグローバル管理者フィールドでRTを構成する必要があります。この手法は、制約されたBGPルート分布のために[RFC4684]で指定されているメカニズムとともに、この仕様とともに使用して、必要なPE/ABRのみが特定のLeaf A-Dルートを処理する必要があることを確認できます。
[RFC7524] specifies that when an ingress PE/ASBR (re-)advertises a VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA. Similar to the inter-AS case, this is actually not really needed for EVPNs. To be consistent with the inter-AS case, the ingress PE does not set the L flag in its originated I-PMSI A-D routes, and it determines the leaves based on the BGP next hops in its received I-PMSI A-D routes, as specified in Section 5.2.
[RFC7524]は、侵入PE/ASBR（RE）がVPLS I-PMSI A-Dルートを宣伝すると、ルートのPTAでLフラグを1に設定することを指定します。AS Inter-ASの場合と同様に、これは実際にはEVPNには実際には必要ありません。Inter-ASの場合と一致するために、Ingress PEは、その起源のI-PMSI A-DルートにLフラグを設定せず、指定されているように、受信したI-PMSI A-DルートのBGP次のホップに基づいて葉を決定します。セクション5.2で。
The same backward-compatibility issue exists, and the same solution as that for the inter-AS case applies, as specified in Section 5.3.
同じ後方互換性の問題が存在し、セクション5.3で指定されているように、AS Inter-Asの場合と同じ解決策が適用されます。
To support multihoming with segmentation, Ethernet Segment Identifier (ESI) labels SHOULD be allocated from a "Domain-wide Common Block" (DCB) [RFC9573] for all tunnel types, including Ingress Replication tunnels [RFC7988]. Via means outside the scope of this document, PEs know that ESI labels are from a DCB, and existing multihoming procedures will then work "as is" (whether a multihomed Ethernet Segment spans segmentation regions or not).
セグメンテーションでマルチホームをサポートするために、イーサネットセグメント識別子（ESI）ラベルは、イングレス複製トンネル[RFC7988]を含むすべてのトンネルタイプの「ドメイン全体の共通ブロック」（DCB）[RFC9573]から割り当てる必要があります。このドキュメントの範囲外の手段を介して、PESはESIラベルがDCBからのものであり、既存のマルチホーム手順が「現状のまま」に機能することを知っています（マルチホームイーサネットセグメントがセグメンテーション領域にスパンするかどうか）。
Not using DCB-allocated ESI labels is outside the scope of this document.
DCBに割り当てられたESIラベルを使用していないことは、このドキュメントの範囲外です。
IANA has assigned the following new EVPN route types in the "EVPN Route Types" registry:
IANAは、「EVPNルートタイプ」レジストリに次の新しいEVPNルートタイプを割り当てました。
+=======+=============================+===========+
| Value | Description | Reference |
+=======+=============================+===========+
| 9 | Per-Region I-PMSI A-D route | RFC 9572 |
+-------+-----------------------------+-----------+
| 10 | S-PMSI A-D route | RFC 9572 |
+-------+-----------------------------+-----------+
| 11 | Leaf A-D route | RFC 9572 |
+-------+-----------------------------+-----------+
Table 3: New Route Types
表3：新しいルートタイプ
IANA has assigned one flag bit from the "Multicast Flags Extended Community" registry created by [RFC9251]:
IANAは、[RFC9251]によって作成された「マルチキャストフラグ拡張コミュニティ」レジストリから1つのフラグビットを割り当てました。
+=====+======================+===========+===================+
| Bit | Name | Reference | Change Controller |
+=====+======================+===========+===================+
| 8 | Segmentation Support | RFC 9572 | IETF |
+-----+----------------------+-----------+-------------------+
Table 4: New Multicast Flag
表4：新しいマルチキャストフラグ
The procedures specified in this document for selective forwarding via S-PMSI/Leaf A-D routes are based on the same procedures as those used for MVPNs [RFC6513] [RFC6514] and VPLS multicast [RFC7117]. The procedures for tunnel segmentation as specified in this document are based on similar procedures used for MVPN inter-AS tunnel segmentation [RFC6514] and inter-area tunnel segmentation [RFC7524], as well as procedures for VPLS multicast inter-AS tunnel segmentation [RFC7117]. When applied to EVPNs, they do not introduce new security concerns beyond those discussed in [RFC6513], [RFC6514], [RFC7117], and [RFC7524]. They also do not introduce new security concerns compared to [RFC7432].
S-PMSI/LEAF A-Dルートを介した選択的転送のためにこのドキュメントで指定された手順は、MVPNS [RFC6513] [RFC6514]およびVPLSマルチキャスト[RFC7117]に使用される手順と同じ手順に基づいています。このドキュメントで指定されているトンネルセグメンテーションの手順は、MVPN間のトンネルセグメンテーション[RFC6514]およびA-A-AREAトンネルセグメンテーション[RFC7524]に使用される同様の手順に基づいています。]。EVPNに適用されると、[RFC6513]、[RFC6514]、[RFC7117]、および[RFC7524]で議論されているものを超えて、新しいセキュリティ上の懸念を導入しません。また、[RFC7432]と比較して、新しいセキュリティ上の懸念も導入しません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
<https://www.rfc-editor.org/info/rfc7117>.
[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>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>.
[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>.
[RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang,
"Explicit Tracking with Wildcard Routes in Multicast VPN",
RFC 8534, DOI 10.17487/RFC8534, February 2019,
<https://www.rfc-editor.org/info/rfc8534>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[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>.
The authors thank Eric Rosen, John Drake, and Ron Bonica for their comments and suggestions.
著者は、コメントと提案について、エリック・ローゼン、ジョン・ドレイク、ロン・ボニカに感謝します。
The following people also contributed to this document through their earlier work in EVPN selective multicast.
以下の人々は、EVPN選択的マルチキャストでの以前の研究を通じてこの文書にも貢献しました。
Junlin Zhang
Huawei Technologies
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China
Email: jackey.zhang@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No. 156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com
Keyur Patel
Arrcus
Email: keyur@arrcus.com
Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com