Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9624 T. Przygienda
Category: Standards Track Juniper Networks
ISSN: 2070-1721 A. Sajassi
Cisco Systems
J. Rabadan
Nokia
August 2024
This document specifies protocols and procedures for forwarding Broadcast, Unknown Unicast, or Multicast (BUM) traffic of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).
このドキュメントは、ビットインデックス明示的複製（BIER）を使用して、イーサネットVPNS（EVPNS）の放送、不明なユニキャスト、またはマルチキャスト（BUM）トラフィックを転送するためのプロトコルと手順を指定します。
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/rfc9624.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9624で取得できます。
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.2. Requirements Language
2. Use of the PMSI Tunnel Attribute
2.1. IP-Based Tunnel and BIER PHP
2.2. Explicit Tracking
2.2.1. Using IMET/SMET Routes
2.2.2. Using S-PMSI/Leaf A-D Routes
2.3. MPLS Label in the PTA
3. Multihoming Split Horizon
4. Data Plane
4.1. Encapsulation and Transmission
4.1.1. At a BFIR That Is an Ingress PE
4.1.2. At a BFIR That Is a P-Tunnel Segmentation Point
4.2. Disposition
4.2.1. At a BFER That Is an Egress PE
4.2.2. At a BFER That Is a P-Tunnel Segmentation Point
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
[RFC7432] and [RFC8365] specify the protocols and procedures for Ethernet VPNs (EVPNs). For Broadcast, Unknown Unicast, or Multicast (BUM) traffic, provider/underlay tunnels are used to carry the BUM traffic. Several kinds of tunnel technologies can be used as specified in [RFC7432] and [RFC8365], and this document specifies the protocols and procedures to use Bit Index Explicit Replication (BIER) [RFC8279] as provider tunnels for EVPN BUM traffic.
[RFC7432]および[RFC8365]は、イーサネットVPN（EVPN）のプロトコルと手順を指定します。ブロードキャスト、不明なユニキャスト、またはマルチキャスト（バム）トラフィックの場合、プロバイダー/アンダーレイトンネルを使用して、バムトラフィックを運びます。[RFC7432]および[RFC8365]で指定されているように、いくつかの種類のトンネル技術を使用できます。このドキュメントは、EVPNバムトラフィックのプロバイダートンネルとしてビットインデックス明示的複製（BIER）[RFC8279]を使用するプロトコルと手順を指定します。
BIER is an architecture that provides optimal multicast forwarding through a "multicast domain" without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol.
Bierは、流量ごとの状態を維持したり、明示的なツリービルディングプロトコルに従事するために中間ルーターを必要とせずに、「マルチキャストドメイン」を介して最適なマルチキャスト転送を提供するアーキテクチャです。
The EVPN BUM procedures specified in [RFC7432] and extended in [RFC9572], [RFC9251], and [CMCAST-ENHANCEMENTS] are much aligned with Multicast VPN (MVPN) procedures [RFC6514], and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN. As such, this document is also very much aligned with [RFC8556], which specifies MVPN with BIER. For terseness, some background, terms, and concepts are not repeated here. Additionally, some text is borrowed verbatim from [RFC8556].
[rfc7432]で指定され、[rfc9572]、[rfc9251]、および[cmcast-enhancements]で拡張されたevpn bum手順は、マルチキャストVPN（MVPN）手順[RFC6514]、およびAN eVPNブロードキャストドメイン（BD）と非常に整合しています。MVPNのVPN。そのため、このドキュメントは[RFC8556]と非常に非常に整合しており、MVPNをBIERで指定しています。Tersenessについては、ここでは背景、用語、概念が繰り返されません。さらに、一部のテキストは[RFC8556]から逐語的に借用されています。
ES:
ES:
Ethernet Segment
イーサネットセグメント
ESI:
ESI:
Ethernet Segment Identifier
イーサネットセグメント識別子
BFR:
BFR:
Bit-Forwarding Router
ビットフォワードルーター
BFIR:
BFIR：
Bit-Forwarding Ingress Router
ビットフォワードイングレスルーター
BFER:
Bfer：
Bit-Forwarding Egress Router
ビットフォワード出力ルーター
BFR-Prefix:
bfr-prefix：
An IP address that uniquely identifies a BFR and is routable in a BIER domain.
BFRを一意に識別し、ビアドメインでルーティング可能なIPアドレス。
C-S:
C-S：
A multicast source address identifying a multicast source located at an EVPN customer site. "C-" stands for "Customer-".
EVPNカスタマーサイトにあるマルチキャストソースを識別するマルチキャストソースアドレス。「C-」は「顧客」の略です。
C-G:
C-G：
A multicast group address used by an EVPN customer.
EVPN顧客が使用するマルチキャストグループアドレス。
C-flow:
C-flow：
A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S, C-G). Sets of C-flows can be denoted by the use of the "C-*" wildcard (see [RFC6625]), e.g., (C-*, C-G).
顧客マルチキャストフロー。各C-flowは、各アドレスが顧客のアドレススペースにある順序付きペア（ソースアドレス、グループアドレス）によって識別されます。特定のCフローの識別子は、通常（C-S、C-G）と書かれています。c-flowのセットは、「c-*」ワイルドカード（[rfc6625]を参照）を使用することによって示される可能性があります。たとえば、（c-*、c-g）。
P-tunnel:
Pトンネル：
A multicast tunnel through the network of one or more service providers used to transport C-flows. "P-" stands for "Provider-".
C-Flowを輸送するために使用される1つ以上のサービスプロバイダーのネットワークを通るマルチキャストトンネル。「P-」は「プロバイダー」の略です。
IMET A-D Route:
IMET A-Dルート：
Inclusive Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the "default" P-tunnel for a particular BD.
包括的マルチキャストイーサネットタグ自動配置ルート。これらのルートは、BGPアップデートメッセージに携帯されており、特定のBDの「デフォルト」Pトンネルを宣伝するために使用されます。
SMET A-D Route:
SMET A-Dルート：
Selective Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the C-flows that the advertising Provider Edge (PE) is interested in.
選択的なマルチキャストイーサネットタグ自動発見ルート。BGPアップデートメッセージに携帯されているこれらのルートは、広告プロバイダーEdge（PE）が関心のあるCフローを宣伝するために使用されます。
PMSI:
PMSI：
Provider Multicast Service Interface [RFC6513]. A conceptual interface used by a PE to send customer multicast traffic to all or some PEs in the same VPN.
プロバイダーマルチキャストサービスインターフェイス[RFC6513]。PEが使用する概念インターフェイスは、同じVPNのすべてまたは一部のPEに顧客マルチキャストトラフィックを送信します。
I-PMSI:
i-pmsi：
Inclusive PMSI. For all PEs in the same VPN.
包括的PMSI。同じVPNのすべてのPEについて。
S-PMSI:
S-PMSI：
Selective PMSI. For some of the PEs in the same VPN.
選択的PMSI。同じVPNの一部のPEの場合。
I-PMSI A-D Route:
i-pmsi a-dルート：
Inclusive PMSI Auto-Discovery route used to advertise the tunnels that instantiate an I-PMSI.
I-PMSIをインスタンス化するトンネルを宣伝するために使用される包括的なPMSIオートディスコーブリルート。
S-PMSI A-D Route:
S-PMSI A-Dルート：
Selective PMSI Auto-Discovery route used to advertise that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels.
特定のc-flowが特定のpターンネルにバインドされている（つまり、移動している）ことを宣伝するために使用される選択的PMSI自動ディスコービリルート。
PTA:
PTA:
PMSI Tunnel Attribute. A BGP attribute used to identify a particular P-tunnel.
PMSIトンネル属性。特定のPトンネルを識別するために使用されるBGP属性。
VXLAN:
vxlan：
Virtual eXtensible Local Area Network [RFC7348]
仮想拡張可能なローカルエリアネットワーク[RFC7348]
NVGRE:
nvgre：
Network Virtualization Using Generic Routing Encapsulation [RFC7637]
一般的なルーティングカプセル化を使用したネットワーク仮想化[RFC7637]
GENEVE:
Geneve：
Generic Network Virtualization Encapsulation [RFC8926]
一般的なネットワーク仮想化カプセル化[RFC8926]
VNI:
VNI:
VXLAN Network Identifier
VXLANネットワーク識別子
VSID:
vsid：
Virtual Subnet Identifier
仮想サブネット識別子
RSVP-TE P2MP:
RSVP-TE P2MP：
Resource Reservation Protocol for Point-to-Multipoint TE Label Switched Paths (LSPs) [RFC4875]
Point-to-MultiPoint TEラベルスイッチ付きパス（LSP）のリソース予約プロトコル[RFC4875]
mLDP P2MP:
MLDP P2MP：
Multipoint Label Distribution Protocol extensions for Point-to-Multipoint LSPs [RFC6388]
ポイントツーマルチポイントLSPのマルチポイントラベル分布プロトコル拡張[RFC6388]
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]で説明されているように解釈されます。
[RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) routes carry a PMSI Tunnel Attribute (PTA) to identify the particular P-tunnel to which one or more BUM flows are being assigned, which is the same as specified in [RFC6514] for MVPN. [RFC8556] specifies the encoding of the PTA for the use of BIER with MVPN. Much of that specification is reused for the use of BIER with EVPN, and much of the text below is borrowed verbatim from [RFC8556].
[RFC7432]は、包括的なマルチキャストイーサネットタグ（IMET）ルートがPMSIトンネル属性（PTA）を運ぶことを指定して、1つ以上のバムフローが割り当てられている特定のPトンネルを識別します。MVPN。[RFC8556]は、MVPNでビアを使用するためのPTAのエンコードを指定します。その仕様の多くは、EVPNでビアを使用するために再利用されており、以下のテキストの多くは[RFC8556]から逐語的に借用されています。
The PTA contains the following fields:
PTAには次のフィールドが含まれています。
* Tunnel Type. The same codepoint 0x0B that IANA has assigned for BIER for MVPN [RFC8556] is used for EVPN as well.
* トンネルタイプ。IANAがMVPN [RFC8556]のBierに割り当てたのと同じコードポイント0x0BもEVPNに使用されます。
* Tunnel Identifier. This field contains three subfields for BIER. The text below is exactly as in [RFC8556].
* トンネル識別子。このフィールドには、ビア用の3つのサブフィールドが含まれています。以下のテキストは[RFC8556]とまったく同じです。
1. The first subfield is a single octet, containing a BIER sub-domain-id (see [RFC8279]). This indicates that packets sent on the PMSI will be sent on the specified BIER sub-domain. How that sub-domain is chosen is outside the scope of this document.
1. 最初のサブフィールドは、ビアサブドメインIDを含む単一のオクテットです（[RFC8279]を参照）。これは、PMSIで送信されたパケットが指定されたビアサブドメインで送信されることを示しています。そのサブドメインがどのように選択されるかは、このドキュメントの範囲外です。
2. The second subfield is a two-octet field containing the BFR-id in the sub-domain identified in the first subfield of the router that is constructing the PTA.
2. 2番目のサブフィールドは、PTAを構築しているルーターの最初のサブフィールドで識別されたサブドメインにBFR-IDを含む2オクテットのフィールドです。
3. The third subfield is the BFR-Prefix (see [RFC8279]) of the router (a BFIR) that is constructing the PTA. The BFR-Prefix will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PTA.
3. 3番目のサブフィールドは、PTAを構築しているルーター（BFIR）のBFR-Prefix（[RFC8279]を参照）です。BFR-Prefixは、A /32 IPv4アドレスまたはA /128 IPv6アドレスのいずれかです。アドレスがIPv4であるかIPv6であるかは、PTAの全長から推測できます。
The BFR-Prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route.
BFR-PREFIXは、BFIRがX-PMSI A-Dルートの発信ルーターであっても、X-PMSI A-Dルートの他のフィールドで運ばれる同じIPアドレスである必要はありません。
* MPLS Label. For EVPN-MPLS [RFC7432], this field contains an upstream-assigned MPLS label. It is assigned by the BFIR. Constraints on how the originating router selects this label are discussed in Section 2.3. For EVPN-VXLAN/NVGRE/GENEVE [RFC8365] [RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of global significance.
* MPLSラベル。EVPN-MPLS [RFC7432]の場合、このフィールドにはアップストリーム割り当てのMPLSラベルが含まれています。BFIRによって割り当てられます。このラベルがこのラベルを選択する方法に関する制約については、セクション2.3で説明します。EVPN-VXLAN/NVGRE/GENEVE [RFC8365] [RFC7348] [RFC7637] [RFC8926]の場合、このフィールドは24ビットVNI/VSIDです。
* Flags. When the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. Details about the use of these flags can be found in Section 2.2.
* フラグ。トンネルタイプがビアの場合、PTAフラグフィールドの2つのフラグが意味があります。これらのフラグの使用に関する詳細は、セクション2.2にあります。
- Leaf Info Required per Flow (LIR-pF) [RFC8534]
- フローごとに必要な葉の情報（LIR-PF）[RFC8534]
- Leaf Info Required (LIR)
- 葉の情報が必要（LIR）
Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D, or per-region I-PMSI A-D route, the route MUST NOT be distributed beyond the boundaries of a BIER domain. That is, any routers that receive the route must be in the same BIER domain as the originator of the route. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-Prefix in the PTA uniquely identifies the originator. As with all MVPN routes, the distribution of these routes is controlled by the provisioning of Route Targets.
「ビア」を指定するPTAがIMET、S-PMSI A-D、または領域ごとのI-PMSI A-Dルートに接続されている場合、ルートはビアドメインの境界を越えて分布してはなりません。つまり、ルートを受け取るルーターは、ルートの発信元と同じビアドメインにある必要があります。オリジネーターが複数のビアドメインにある場合、ルートは、PTAのBFR-PREFIXがオリジネーターを一意に識別するビアドメイン内にのみ分布する必要があります。すべてのMVPNルートと同様に、これらのルートの分布は、ルートターゲットのプロビジョニングによって制御されます。
When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP header (and UDP header in the case of VXLAN/GENEVE) is not included in the BIER payload, except when it is known a priori that BIER Penultimate Hop Popping (PHP) [BIER-PHP] is used in the BIER domain and the encapsulation (after the BIER header is popped) between the BIER Penultimate Hop and the egress PE does not have a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case, the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer IP header, a well-known IP multicast address (224.0.0.122 in the case of IPv4 or FF02:0:0:0:0:0:0:14 in the case of IPv6) is used as the destination address, and the egress PEs MUST be set up to receive and process packets addressed to the destination address. The address is used for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be used to identify BDs.
vxlan/nvgre/geneveがEVPNに使用される場合、デフォルトでは、Bierペイロードには、Bierペイロードに含まれていない外部IPヘッダー（およびVXLAN/GENEVEの場合のUDPヘッダー）は、Bier Penultimate Hop Poppingが知られている場合を除き、Bierペイロードに含まれていません。（PHP）[Bier-PHP]はBierドメインで使用され、Bier Headerの間にカプセル化（Bierヘッダーがポップされた後）とEgress PEには、次のヘッダーがVXLAN/NVGRE/GENEVEであることを示す方法がありません。その場合、完全なVXLAN/NVGRE/GENEVEカプセル化を使用する必要があります。外側のIPヘッダーでは、有名なIPマルチキャストアドレス（IPv4またはFF02：0：0：0：0：0：0：0：0：14の場合の224.0.0.0.122）が宛先アドレスとして使用されます。、そして、宛先アドレスにアドレス指定されたパケットを受信して処理するために、出力PEを設定する必要があります。アドレスはすべてのBDSに使用され、内側のVXLAN/NVGRE/GENEVEヘッダーを使用してBDSを特定します。
When using BIER to transport an EVPN BUM data packet through a BIER domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways as described in the following two sections.
Bierを使用してEVPNバムデータパケットをBierドメインから輸送する場合、Ingress PEはBFIRとして機能します（[RFC8279]を参照）。BFIRは、パケットを配信する必要があるBFERのセットを決定する必要があります。これは、次の2つのセクションで説明されている2つの方法のいずれかで実行できます。
Both IMET and SMET routes provide explicit tracking functionality.
IMETルートとSMETルートの両方が、明示的な追跡機能を提供します。
For an inclusive PMSI, the set of BFERs (egress PEs) includes the originators of all IMET routes for a BD. For a selective PMSI, the set of BFERs (egress PEs) includes the originators of corresponding SMET routes.
包括的PMSIの場合、BFERSのセット（出口PE）には、BDのすべてのIMETルートの発信元が含まれます。選択的なPMSIの場合、BFERSのセット（出口PES）には、対応するSMETルートの発信者が含まれます。
The SMET routes do not carry a PTA. When an ingress PE sends traffic on a selective tunnel using BIER, it uses the upstream-assigned label that is advertised in its IMET route.
SMETルートはPTAを運びません。Ingress PEがビアを使用して選択的トンネルにトラフィックを送信すると、IMETルートで宣伝されているアップストリーム割り当てのラベルを使用します。
When only selective forwarding is used for all flows and without tunnel segmentation, SMET routes are used without the need for S-PMSI A-D routes. Otherwise, the procedures in the following section apply.
すべてのフローに選択的転送のみが使用され、トンネルセグメンテーションなしでは、S-PMSI A-Dルートを必要とせずにSMETルートが使用されます。それ以外の場合、次のセクションの手順が適用されます。
There are two cases where S-PMSI/Leaf A-D routes are used as discussed in the following two sections.
次の2つのセクションで説明されているように、S-PMSI/LEAF A-Dルートが使用される2つのケースがあります。
With the SMET procedure, a PE advertises a SMET route for each (C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits (ACs), and each SMET route is tracked by every PE in the same BD. It may be desired that SMET routes are not used in order to reduce the burden of explicit tracking.
SMETの手順では、PEはそれぞれ（C-S、C-G）または（C-*、C-G）の各スマートルートを宣伝し、アタッチメントサーキット（ACS）で学習し、各SMETルートはすべてのPEで追跡されます。bd。明示的な追跡の負担を軽減するために、SMETルートは使用されないことが望まれる場合があります。
In this case, most multicast traffic will follow the I-PMSI (advertised via the IMET route) and only some flows will follow S-PMSIs. To achieve that, S-PMSI/Leaf A-D routes can be used, as specified in [RFC9572].
この場合、ほとんどのマルチキャストトラフィックはI-PMSI（IMETルートを介して宣伝されている）に従い、一部のフローのみがS-PMSISに従います。それを達成するために、[RFC9572]で指定されているように、S-PMSI/LEAF A-Dルートを使用できます。
The rules specified in Sections 2.2.1 and 2.2.2 of [RFC8556] apply.
[RFC8556]のセクション2.2.1および2.2.2で指定されたルールが適用されます。
Another case where S-PMSI/Leaf A-D routes are necessary is tunnel segmentation, which is also specified in [RFC9572] and further clarified in [CMCAST-ENHANCEMENTS] for segmentation with SMET routes. This is only applicable to EVPN-MPLS.
S-PMSI/LEAF A-Dルートが必要な別のケースは、[RFC9572]でも指定されており、SMETルートとのセグメンテーションのために[CMCast-Enhancements]でさらに明確にされているトンネルセグメンテーションです。これは、EVPN-MPLSにのみ適用されます。
The rules specified in Section 2.2.1 of [RFC8556] apply. Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the LIR-pF flag cannot be used with segmentation.
[RFC8556]のセクション2.2.1で指定されたルールが適用されます。[RFC8556]のセクション2.2.2は適用されません。MVPNのように、LIR-PFフラグをセグメンテーションで使用できないからです。
As with the MVPN case, "Use of the PMSI Tunnel Attribute in Leaf A-D Routes" (Section 3 of [RFC8556]) applies.
MVPNの場合と同様に、「Leaf A-DルートでのPMSIトンネル属性の使用」（[RFC856]のセクション3）が適用されます。
Notice that [RFC8556] refers to procedures specified in [RFC6625] and [RFC8534]. Those two documents were specified for MVPN but apply to IP multicast payload in EVPN as well.
[RFC8556]は[RFC6625]および[RFC8534]で指定された手順を指すことに注意してください。これらの2つのドキュメントはMVPN用に指定されましたが、EVPNのIPマルチキャストペイロードにも適用されます。
Rules in Section 2.1 of [RFC8556] apply, EXCEPT the following three bullets (they do NOT apply to EVPN) in that section:
[RFC8556]のセクション2.1のルールが適用されます。ただし、次の3つの弾丸（EVPNには適用されません）を除きます。
* If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs MUST contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet.
* 2つのルートに同じアドレスファミリ識別子（AFI）値がない場合、それぞれのPTAには異なるMPLSラベル値を含める必要があります。これにより、出力PEが指定されたラベルを使用してデータパケットを受信すると、出力PEがラベルからペイロードがIPv4パケットかIPv6パケットかを推測できます。
* If the BFIR is an ingress PE supporting MVPN extranet [RFC7900] functionality, and if the two routes originate from different VRFs on this ingress PE, then the respective PTAs of the two routes MUST contain different MPLS label values.
* BFIRがMVPNエクストラネット[RFC7900]機能をサポートする侵入PEであり、2つのルートがこの侵入PEの異なるVRFに由来する場合、2つのルートのそれぞれのPTAには異なるMPLSラベル値を含める必要があります。
* If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routes MUST contain different MPLS label values.
* BFIRがMVPNエクストラネットの「エクストラネット分離」機能をサポートする侵入PEである場合（[RFC7900]のセクション7.3を参照）、1つのルートが「エクストラネット分離」拡張コミュニティを運ぶが、もう1つはそうではありません。2つのルートのPTAには、異なるMPLSラベル値を含める必要があります。
For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify the ES from which a BUM packet originates. A PE receiving that packet from the core side will not forward it to the same ES. The procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels, using downstream- and upstream-assigned ESI labels, respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local bias procedures, where a PE receiving a BUM packet from the core side knows the ingress PE due to encapsulation; therefore, the PE does not forward the packet to any multihoming ESes that the ingress PE is on. This is because the ingress PE already forwarded the packet to those ESes, regardless of whether the ingress PE is a Designated Forwarder for those ESes.
EVPN-MPLSの場合、[RFC7432]は、BUMパケットが発生するESを識別するためにESIラベルの使用を指定します。コア側からそのパケットを受け取るPEは、同じESに転送しません。この手順は、下流および上流のESIラベルをそれぞれ使用して、Ingress Replication（IR）およびRSVP-TE/MLDP P2MPトンネルの両方で機能します。EVPN-VXLAN/NVGRE/GENEVEの場合、[RFC8365]はローカルバイアス手順を指定します。これにより、コアサイドからバムパケットを受け取るPEがカプセル化のために侵入PEを知っています。したがって、PEは、侵入PEがオンになっているマルチホームESEにパケットを転送しません。これは、イングレスPEが既にそれらのESEにパケットを転送しているためです。
With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/GENEVE, as the BFIR-id in the BIER header identifies the ingress PE. For EVPN-MPLS, ESI label procedures also still apply, though two upstream-assigned labels will be used (one for identifying the BD and one for identifying the ES) -- the same as in the case of using a single P2MP tunnel for multiple BDs. The BFIR-id in the BIER header identifies the ingress PE that assigned those two labels.
Bierを使用すると、BierヘッダーのBFIR-IDが侵入PEを識別するため、局所バイアス手順は依然としてEVPN-VXLAN/NVGRE/GENEVEに適用されます。EVPN-MPLSの場合、ESIラベルの手順も適用されますが、2つのアップストリーム割り当てされたラベルが使用されます（1つはBDを識別するために、もう1つはESを識別するために1つ） - 複数に単一のP2MPトンネルを使用する場合と同じBDS。BierヘッダーのBFIR-IDは、これらの2つのラベルを割り当てた侵入PEを識別します。
Like MVPN, the EVPN application plays the role of the "multicast flow overlay" as described in [RFC8279].
MVPNと同様に、EVPNアプリケーションは[RFC8279]に記載されているように、「マルチキャストフローオーバーレイ」の役割を果たします。
A BFIR could be either an ingress PE or a P-tunnel segmentation point. The procedures are slightly different as described below.
BFIRは、侵入PEまたはPトンネルセグメンテーションポイントのいずれかです。手順は、以下に説明するようにわずかに異なります。
To transmit a BUM data packet, an ingress PE first determines the route matched for transmission and routes for tracking leaves according to the following rules.
Bum Data Packetを送信するために、Ingress PEが最初に、次のルールに従って葉を追跡するための送信とルートに一致するルートを決定します。
1. If selective forwarding is not used or is not an IP multicast packet after the Ethernet header, the IMET route originated for the BD by the ingress PE is the route matched for transmission. Leaf-tracking routes are all other received IMET routes for the BD.
1. 選択的転送が使用されていない場合、またはイーサネットヘッダーの後にIPマルチキャストパケットでない場合、IMETルートは、イングレスPEによってBDのために発生しました。リーフトラッキングルートは、BDの他のすべての受信IMETルートです。
2. Otherwise, if selective forwarding is used for all IP multicast traffic based on SMET routes, the IMET route originated for the BD by the ingress PE is the route matched for transmission. Received SMET routes for the BD, whose source and destination address fields match the packet's source and destination IP address, are leaf-tracking routes.
2. それ以外の場合、SMETルートに基づいたすべてのIPマルチキャストトラフィックに選択的転送が使用されている場合、IMETルートは、イングレスPEによってBDに由来します。BDのSMETルートを受け取りました。BDは、パケットのソースおよび宛先IPアドレスと一致するソースおよび宛先アドレスフィールドがリーフトラッキングルートです。
3. Otherwise, the route matched for transmission is the S-PMSI A-D route originated by the ingress PE for the BD, whose source and destination address fields match the packet's source and destination IP address and have a PTA specifying a valid tunnel type that is not "no tunnel info". Leaf-tracking routes are determined as follows:
3. それ以外の場合、送信に一致するルートは、BDのIngress PEが発信するS-PMSI A-Dルートです。そのソースと宛先アドレスフィールドは、パケットのソースおよび宛先IPアドレスと一致し、そうでない有効なトンネルタイプを指定するPTAを持っています」トンネル情報なし」。葉の追跡ルートは次のように決定されます。
a. If the match for the transmission route carries a PTA that has the LIR flag set but does not have the LIR-pF flag set, the routes matched for tracking are Leaf A-D routes whose Route Key field is identical to the NLRI of the S-PMSI A-D route.
a. トランスミッションルートの一致にLIRフラグセットがあるがLIR-PFフラグセットがないPTAがある場合、追跡に一致するルートは、ルートキーフィールドがS-PMSIのNLRIと同一のリーフA-Dルートです。A-Dルート。
b. If the match for the transmission route carries a PTA that has the LIR-pF flag, the leaf-tracking routes are Leaf A-D routes whose Route Key field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534].
b. トランスミッションルートの一致にLIR-PFフラグがあるPTAが搭載されている場合、リーフトラッキングルートは、セクションで説明されている手順に従ってS-PMSI A-DルートのNLRIから派生したルートキーフィールドが葉のA-Dルートです。[RFC8534]の5.2。
Note that in both cases, SMET routes may be used in lieu of Leaf A-D routes, as a PE may omit the Leaf A-D route in response to an S-PMSI A-D route with the LIR or LIR-pF bit set if a SMET route with the corresponding Tag, Source, and Group fields is already originated [RFC9572]. In particular, in the second case above, even though the SMET route does not have a PTA attached, it is still considered a Leaf A-D route in response to a wildcard S-PMSI A-D route with the LIR-pF bit set.
どちらの場合も、SMETルートは、SMETルートがある場合、PEはLIRまたはLIR-PFビットを設定したS-PMSI A-Dルートに応じて葉のA-Dルートを省略する可能性があるため、SMETルートはLeaf A-Dルートの代わりに使用される可能性があることに注意してください。対応するタグ、ソース、およびグループフィールドはすでに発生しています[RFC9572]。特に、上記の2番目のケースでは、SMETルートにはPTAが接続されていない場合でも、LIR-PFビットセットを備えたワイルドカードS-PMSI A-Dルートに応じて、リーフA-Dルートと見なされます。
4. Otherwise, the route matched for transmission and leaf-tracking routes are determined as in rule 1.
4. それ以外の場合、トランスミッションおよびリーフトラッキングルートと一致するルートは、ルール1のように決定されます。
If no route is matched for transmission, the packet is not forwarded onto a P-tunnel. If the tunnel that the ingress determines to use based on the route matched for transmission (and considering interworking with PEs that do not support certain tunnel types per procedures in [RFC9251]) requires leaf tracking (e.g., Ingress Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf-tracking routes, the packet will not be forwarded onto a P-tunnel either.
トランスミッション用のルートが一致しない場合、パケットはPトンネルに転送されません。イングレスが送信に一致するルートに基づいて使用することを決定するトンネル（および[RFC9251]の手順ごとの特定のトンネルタイプをサポートしないPEとの相互作用を検討する）には、葉の追跡が必要です（たとえば、イングレス複製、RSVP-TE P2MPトンネル、またはbier）しかし、葉トラッキングルートはありません。パケットもPトンネルに転送されません。
The following text assumes that BIER is the determined tunnel type. The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if the following conditions are all met:
次のテキストは、Bierが決定されたトンネルタイプであると想定しています。Ingress PEは、次の条件がすべて満たされている場合、[RFC7432]ごとに上流に割り当てられたESIラベルをプッシュします。
* The packet is received on a multihomed ES.
* パケットは、マルチホームのESで受信されます。
* It is EVPN-MPLS.
* EVPN-MPLSです。
* The ESI label procedure is used for split horizon.
* ESIラベル手順は、スプリットホライズンに使用されます。
The MPLS label from the PTA of the route matched for transmission is then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the packet with the VNI/VSID set to the value in the PTA's Label field, and then an IP/UDP header is prepended if needed (e.g., for PHP purposes).
送信に一致するルートのPTAからのMPLSラベルは、EVPN-MPLのパケットのラベルスタックに押し込まれます。EVPN-VXLAN/NVGRE/GENEVEの場合、VXLAN/NVGRE/GENEVEヘッダーは、PTAのラベルフィールドの値に設定されたVNI/VSIDセットを使用してパケットに加えられ、必要に応じてIP/UDPヘッダーが準備されます（例えば、PHPの目的で）。
Then, the packet is encapsulated in a BIER header and forwarded according to the procedures of [RFC8279] and [RFC8296]. Specifically, see "Imposing and Processing the BIER Encapsulation" (Section 3 of [RFC8296]). The Proto field in the BIER header is set to 2 in the case of EVPN-MPLS, 7/8/9 in the case of EVPN-VXLAN/NVGRE/ GENEVE (Section 5) when an IP header is not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE.
次に、パケットはビアヘッダーにカプセル化され、[RFC8279]と[RFC8296]の手順に従って転送されます。具体的には、「Bierカプセル化の課題と処理」（[RFC8296]のセクション3）を参照してください。Bierヘッダーのプロトフィールドは、EVPN-MPLSの場合、EVPN-VXLAN/NVGRE/GENEVE（セクション5）の場合は7/8/9に設定されています。6 IPヘッダーがEVPN-VXLAN/NVGRE/GENEVEに使用されている場合。
To create the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. This is determined from the set of leaf-tracking routes.
特定のパケットの適切なビアヘッダーを作成するには、BFIRはそのパケットを受信する必要があるすべてのBFERを知る必要があります。これは、リーフトラッキングルートのセットから決定されます。
In this case, the encapsulation for the upstream segment of the P-tunnel includes (among other things) a label that identifies the x-PMSI or IMET A-D route that is the match for reception on the upstream segment. The segmentation point re-advertised the route into one or more downstream regions. Each instance of the re-advertised route for a downstream region has a PTA that specifies the tunnel for that region. For any particular downstream region, the route matched for transmission is the re-advertised route, and the leaf-tracking routes are determined as follows, if needed, for the tunnel type:
この場合、Pトンネルの上流セグメントのカプセル化には、（とりわけ）上流セグメントでのレセプションの一致であるX-PMSIまたはIMET A-Dルートを識別するラベルが含まれています。セグメンテーションポイントは、ルートを1つ以上の下流領域に再告発しました。下流領域の再承認されたルートの各インスタンスには、その領域のトンネルを指定するPTAがあります。特定のダウンストリーム領域では、伝送と一致するルートは再承認されたルートであり、トンネルタイプについては、必要に応じて、葉の追跡ルートが次のように決定されます。
* If the route matched for transmission is an x-PMSI route, it must have the LIR flag set in its PTA, and the leaf-tracking routes are all the matching Leaf A-D and SMET routes received in the downstream region.
* トランスミッションに一致するルートがX-PMSIルートである場合、PTAにLIRフラグが設定されている必要があり、リーフトラッキングルートはすべて、下流領域で受け取った一致するリーフA-DおよびSMETルートです。
* If the route matched for transmission is an IMET route, the leaf-tracking routes are all the IMET routes for the same BD received in the downstream region.
* トランスミッションに一致するルートがIMETルートである場合、リーフトラッキングルートは、下流の領域で受け取った同じBDのすべてのIMETルートです。
If the downstream region uses BIER, the packet is forwarded as follows: the upstream segmentation's encapsulation is removed and the above-mentioned label is swapped to the upstream-assigned label in the PTA of the route matched for transmission, and then a BIER header is imposed as in Section 4.1.1.
下流領域がビアを使用する場合、パケットは次のように転送されます。上流のセグメンテーションのカプセル化が削除され、上記のラベルがトランスミッションのために一致するルートのPTAで上流のラベルに交換され、ビアヘッダーはバイアヘッダーです。セクション4.1.1のように課されます。
The same procedures in Section 4.2 of [RFC8556] are followed for EVPN-MPLS, except for some EVPN specifics that are discussed in the following two subsections of this document.
[RFC8556]のセクション4.2の同じ手順には、このドキュメントの次の2つのサブセクションで説明されているEVPNの詳細を除き、EVPN-MPLSについても追跡されます。
For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the payload is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID field in the VXLAN/NVGRE/GENEVE header is used to determine the corresponding BD.
EVPN-VXLAN/NVGRE/GENEVEの場合、唯一の違いは、ペイロードがVXLAN/NVGRE/GENEVE（IPヘッダーの有無にかかわらず）であり、VXLAN/NVGRE/GENEVEヘッダーのVNI/VSIDフィールドであることです。bd。
Once the corresponding BD is determined from the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per [RFC7432] or [RFC8365] are followed. In the case of EVPN-MPLS, if there is an inner label in the label stack following the BIER header, that inner label is considered the upstream-assigned ESI label for split-horizon purposes.
対応するBDがアップストリーム割り当てのラベルまたはVNI/VSIDから決定されると、[RFC7432]または[RFC8365]あたりのEVPN転送手順が続きます。EVPN-MPLSの場合、Bierヘッダーに続いてラベルスタックに内側のラベルがある場合、その内側のラベルは、スプリットホリゾンの目的で上流に割り当てられたESIラベルと見なされます。
This is only applicable to EVPN-MPLS. The same procedures in Section 4.2.2 of [RFC8556] are followed, subject to multihoming procedures specified in [RFC9572].
これは、EVPN-MPLSにのみ適用されます。[RFC8556]のセクション4.2.2の同じ手順に従って、[RFC9572]で指定されたマルチホーム手順を条件としています。
Per this document, IANA has registered the following three values in the "BIER Next Protocol Identifiers" registry:
このドキュメントに従って、IANAは「Bier Next Protocol Identiers」レジストリに次の3つの値を登録しています。
+=======+================================+===========+
| Value | Description | Reference |
+=======+================================+===========+
| 7 | Payload is VXLAN encapsulated | RFC 9624 |
| | (no IP/UDP header) | |
+-------+--------------------------------+-----------+
| 8 | Payload is NVGRE encapsulated | RFC 9624 |
| | (no IP header) | |
+-------+--------------------------------+-----------+
| 9 | Payload is GENEVE encapsulated | RFC 9624 |
| | (no IP/UDP header) | |
+-------+--------------------------------+-----------+
Table 1: BIER Next Protocol Identifiers Registry
表1：Bier Nextプロトコル識別子レジストリ
IANA has also assigned an IPv4 and an IPv6 multicast address for the case discussed in Section 2.1.
IANAは、セクション2.1で説明したケースにIPv4とIPv6マルチキャストアドレスも割り当てました。
The following entry has been added to the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:
次のエントリが「ローカルネットワーク制御ブロック（224.0.0.0-224.0.0.255（224.0.0/24））」に追加されました。
Address(es):
アドレス（es）：
224.0.0.122
224.0.0.122
Description:
説明：
Network Virtualization Overlay (NVO) BUM Traffic
ネットワーク仮想化オーバーレイ（NVO）バムトラフィック
Reference:
参照：
RFC 9624
RFC 9624
The following entry has been added to the "Link-Local Scope Multicast Addresses" registry for IPv6:
次のエントリは、IPv6の「リンクローカルスコープマルチキャストアドレス」レジストリに追加されました。
Address(es):
アドレス（es）：
FF02:0:0:0:0:0:0:14
FF02：0：0：0：0：0：0：14
Description:
説明：
Network Virtualization Overlay (NVO) BUM Traffic
ネットワーク仮想化オーバーレイ（NVO）バムトラフィック
Reference:
参照：
RFC 9624
RFC 9624
This document is about using BIER as provider tunnels for EVPN. It is very similar to using BIER as MVPN provider tunnels and does not introduce additional security implications beyond what have been discussed in the EVPN base protocol specification [RFC7432] and MVPN using BIER [RFC8556].
このドキュメントは、EVPNのプロバイダートンネルとしてBierを使用することに関するものです。BierをMVPNプロバイダートンネルとして使用することと非常によく似ており、EVPNベースプロトコル仕様[RFC7432]およびBier [RFC8556]を使用したMVPNで議論されているものを超えて追加のセキュリティへの影響を導入しません。
[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>.
[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>.
[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>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
RFC 7900, DOI 10.17487/RFC7900, June 2016,
<https://www.rfc-editor.org/info/rfc7900>.
[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>.
[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>.
[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>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[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>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[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>.
[BIER-PHP] Zhang, Z., "BIER Penultimate Hop Popping", Work in
Progress, Internet-Draft, draft-ietf-bier-php-11, 6
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-php-11>.
[CMCAST-ENHANCEMENTS]
Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN
C-Multicast Routes Enhancements", Work in Progress,
Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-
enhancements-04, 17 March 2024,
<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
mvpn-evpn-cmcast-enhancements-04>.
[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>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
The authors thank Eric Rosen for his review and suggestions. Additionally, much of the text is borrowed verbatim from [RFC8556].
著者は、彼のレビューと提案をしてくれたエリック・ローゼンに感謝します。さらに、テキストの多くは[RFC8556]から逐語的に借りられています。
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Tony Przygienda
Juniper Networks
Email: prz@juniper.net
Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com