[要約] RFC 9489は、EVPNとPBB-EVPNネットワークでLSP Pingを使用してデータ面の障害を検出するメカニズムを説明しています。これは、MPLSネットワークにおける広く展開されたOAMメカニズムです。
Internet Engineering Task Force (IETF) P. Jain
Request for Comments: 9489 A. Sajassi
Category: Standards Track S. Salam
ISSN: 2070-1721 Cisco
S. Boutros
Ciena
G. Mirsky
Ericsson
November 2023
Label Switched Path (LSP) Ping is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) networks.
ラベルスイッチ付きパス（LSP）Pingは、MPLSネットワークの広く展開された運用、管理、およびメンテナンス（OAM）メカニズムです。このドキュメントでは、MPLSベースのイーサネットVPN（EVPN）およびプロバイダーバックボーンブリッジングEVPN（PBB-EVPN）ネットワークでLSP Pingを使用してデータプレーン障害を検出するメカニズムについて説明します。
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/rfc9489.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9489で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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
2. Specification of Requirements
3. Terminology
4. Target FEC Stack Sub-TLVs
4.1. EVPN MAC/IP Sub-TLV
4.2. EVPN Inclusive Multicast Sub-TLV
4.3. EVPN Ethernet Auto-Discovery (A-D) Sub-TLV
4.3.1. Ethernet Tag Value
4.3.2. Per-ES EVPN Auto-Discovery Route with Different RDs
4.3.3. EVPN VPWS
4.4. EVPN IP Prefix Sub-TLV
5. Encapsulation of OAM Ping Packets
6. Operations
6.1. Unicast Data Plane Connectivity Checks
6.2. Inclusive Multicast Data Plane Connectivity Checks
6.2.1. Ingress Replication
6.2.2. Using P2MP P-Tree
6.2.3. Controlling Echo Responses When Using P2MP P-Tree
6.3. EVPN Aliasing Data Plane Connectivity Check
6.4. EVPN IP Prefix (RT-5) Data Plane Connectivity Check
7. Security Considerations
8. IANA Considerations
8.1. Sub-TLV Type
8.2. New Return Codes
9. Normative References
Acknowledgments
Authors' Addresses
[RFC7432] describes MPLS-based EVPN technology. An EVPN comprises one or more Customer Edge devices (CEs) connected to one or more Provider Edge devices (PEs). The PEs provide Layer 2 (L2) EVPN among the CE(s) over the MPLS core infrastructure. In EVPN networks, the PEs advertise the Media Access Control (MAC) addresses learned from the locally connected CE(s), along with the MPLS label, to remote PE(s) in the control plane using multiprotocol BGP [RFC4760]. EVPN enables multihoming of CE(s) connected to multiple PEs and load balancing of traffic to and from multihomed CE(s).
[RFC7432]は、MPLSベースのEVPNテクノロジーについて説明しています。EVPNは、1つ以上のプロバイダーエッジデバイス（PES）に接続された1つまたは複数の顧客エッジデバイス（CES）で構成されています。PESは、MPLSコアインフラストラクチャ上のCE（S）の間でレイヤー2（L2）EVPNを提供します。EVPNネットワークでは、PESは、マルチプロトコルBGP [RFC4760]を使用して、局所的に接続されたCE（S）とMPLSラベルから学習したアドレスをMPLSラベルからコントロールプレーンのリモートPEに宣伝します。EVPNは、複数のPEに接続されたCE（S）のマルチホームと、マルチホーム化されたCE（S）との間のトラフィックの負荷分散を可能にします。
[RFC7623] describes the use of Provider Backbone Bridging EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in the data plane and only advertises Backbone MAC (B-MAC) addresses in a control plane using BGP.
[RFC7623]は、プロバイダーバックボーンブリッジングevpnの使用について説明しています。PBB-EVPNは、データプレーンで顧客MAC（C-MAC）学習を維持し、BGPを使用してコントロールプレーンでバックボーンMAC（B-MAC）アドレスのみを宣伝します。
Procedures for simple and efficient mechanisms to detect data plane failures using LSP Ping in MPLS networks are well defined in [RFC8029] and [RFC6425]. The basic idea for the LSP Ping mechanism is to send an MPLS Echo Request packet along the same data path as data packets belonging to the same Forwarding Equivalent Class (FEC). The Echo Request packet carries the FEC being verified in the Target FEC Stack TLV [RFC8029]. Once the Echo Request packet reaches the end of the MPLS path, it is sent to the control plane of the egress PE. The Echo Request packet contains sufficient information to verify the correctness of data plane operations and validate the data plane against the control plane. The egress PE sends the results of the validation in an Echo Reply packet to the originating PE of the Echo Request packet.
MPLSネットワークでLSP Pingを使用してデータ平面障害を検出するためのシンプルで効率的なメカニズムの手順は、[RFC8029]および[RFC6425]で明確に定義されています。LSP Pingメカニズムの基本的なアイデアは、同じフォワーディング同等のクラス（FEC）に属するデータパットと同じデータパスに沿ってMPLSエコーリクエストパケットを送信することです。ECHO要求パケットは、ターゲットFECスタックTLV [RFC8029]で検証されているFECを運びます。エコーリクエストパケットがMPLSパスの端に到達すると、出力PEのコントロールプレーンに送信されます。Echo Request Packetには、データプレーンの操作の正しさを検証し、制御プレーンに対するデータプレーンを検証するのに十分な情報が含まれています。出力PEは、エコーリクエストパケットの発信PEに、エコー応答パケットで検証の結果を送信します。
This document defines procedures to detect data plane failures using LSP Ping in MPLS networks deploying EVPN and PBB-EVPN. This document defines four new sub-TLVs for the Target FEC Stack TLV with the purpose of identifying the FEC on the egress PE.
このドキュメントでは、EVPNおよびPBB-EVPNを展開するMPLSネットワークでLSP Pingを使用してデータプレーンの障害を検出する手順を定義します。このドキュメントでは、ターゲットFECスタックTLVの4つの新しいサブTLVを、出口PEでFECを識別する目的で定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A-D:
広告：
Auto-Discovery
自動発見
B-MAC:
b-mac：
Backbone MAC
バックボーンMac
BUM:
お尻：
Broadcast, Unknown Unicast, and Multicast
ブロードキャスト、不明なユニキャスト、マルチキャスト
CE:
CE：
Customer Edge device
顧客エッジデバイス
C-MAC:
c-mac：
Customer MAC
カスタマーマック
DF:
DF：
Designated Forwarder
指定されたフォワーダー
ES:
ES：
Ethernet Segment
イーサネットセグメント
ESI:
ESI：
Ethernet Segment Identifier
イーサネットセグメント識別子
EVI:
Evi：
EVPN Instance Identifier that globally identifies the EVPN Instance
EVPNインスタンスをグローバルに識別するEVPNインスタンス識別子
EVPN:
EVPN：
Ethernet Virtual Private Network
イーサネット仮想プライベートネットワーク
FEC:
FEC：
Forwarding Equivalent Class
同等のクラスを転送します
G-ACh:
g-ach：
Generic Associated Channel
一般的な関連チャネル
GAL:
ギャル：
G-ACh Label
G-achラベル
MAC-VRF:
MAC-VRF：
A Virtual Routing and Forwarding table for MAC addresses on a PE
PEのMacアドレスの仮想ルーティングと転送テーブル
ND:
ND：
Neighbor Discovery
隣人の発見
OAM:
OAM：
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
P2MP:
P2MP：
Point-to-Multipoint
ポイントツーマルチポイント
PBB-EVPN:
PBB-EVPN：
Provider Backbone Bridging EVPN
プロバイダーバックボーンブリッジングevpn
PE:
PE：
Provider Edge device
プロバイダーエッジデバイス
VPWS:
VPWS：
Virtual Private Wire Service
仮想プライベートワイヤーサービス
This document introduces four new Target FEC Stack sub-TLVs that are included in the MPLS Echo Request packet. The Echo Request packets are used for connectivity checks in the data plane in EVPN and PBB-EVPN networks. The Target FEC Stack sub-TLVs MAY be used to validate that an identifier for a given EVPN is programmed at the target node.
このドキュメントでは、MPLSエコーリクエストパケットに含まれる4つの新しいターゲットFECスタックサブTLVを紹介します。ECHO要求パケットは、EVPNおよびPBB-EVPNネットワークのデータプレーンの接続チェックに使用されます。ターゲットFECスタックサブTLVを使用して、特定のEVPNの識別子がターゲットノードでプログラムされていることを検証できます。
The EVPN MAC/IP sub-TLV identifies the target MAC, MAC/IP binding for ARP/ND, or IP address for an EVI under test at an egress PE. This sub-TLV is included in the Echo Request sent by an EVPN/PBB-EVPN PE to a peer PE.
EVPN MAC/IP SUB-TLVは、ターゲットMAC、ARP/NDのMAC/IPバインディング、または出口PEでテスト中のEVIのIPアドレスを識別します。このサブTLVは、EVPN/PBB-EVPN PEからPEER PEに送信されたエコー要求に含まれています。
The fields of the EVPN MAC/IP sub-TLV are derived from the MAC/IP Advertisement route defined in Section 7.2 of [RFC7432] and have the format shown in Figure 1. The fields of the EVPN MAC/IP sub-TLV should be set according to the following, which is consistent with [RFC7432] and [RFC7623]:
EVPN MAC/IP SUB-TLVのフィールドは、[RFC7432]のセクション7.2で定義されているMAC/IP広告ルートから派生し、図1に形式を示しています。EVPNMAC/IP Sub-TLVのフィールドは[RFC7432]および[RFC7623]と一致する以下に従って設定します。
* The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of this field is always 0 as per Section 5.2 of [RFC7623].
* イーサネットタグIDフィールドは、EVPN VLAN-AWAREバンドルサービス[RFC7432]の0または有効なVLAN IDにすることができます。PBB-EVPNの場合、[RFC7623]のセクション5.2に従って、このフィールドの値は常に0です。
* The Ethernet Segment Identifier field is a 10-octet field. For EVPN, it is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN, the Ethernet Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load balancing) or to MAX-ESI (for multihomed segments with per-flow load balancing) as described in Section 5.2 of [RFC7623].
* イーサネットセグメント識別子フィールドは10オクテットのフィールドです。EVPNの場合、シングルホームESの場合は0に設定されています。PBB-EVPNの場合、イーサネットセグメント識別子フィールドは、0に設定する必要があります（単一ホームのセグメントまたはI-SID負荷バランスごとのマルチホームセグメントの場合）[RFC7623]のセクション5.2で説明されているように。
* The MAC Addr Len field specifies the MAC length in bits. Only 48-bit MAC addresses are supported as this document follows the MAC address length supported by [RFC7432].
* Mac Addr Lenフィールドは、ビットでMacの長さを指定します。このドキュメントは[RFC7432]でサポートされているMACアドレスの長さに従うため、48ビットのMACアドレスのみがサポートされています。
* The MAC Address field is set to the 6-octet MAC address.
* MACアドレスフィールドは、6オクテットのMACアドレスに設定されています。
* The IP Address field is optional. When the IP Address field is not present, the IP Addr Len field is set to 0. When the IP Address field is present, the IP Addr Len field is in bits and is set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
* IPアドレスフィールドはオプションです。IPアドレスフィールドが存在しない場合、IP ADDR LENフィールドは0に設定されています。IPアドレスフィールドが存在する場合、IP ADDR LENフィールドはビットになり、IPv4アドレスの場合は32、IPv6アドレスの場合は128に設定されます。
* The Must Be Zero fields are set to 0. The receiving PE should ignore the Must Be Zero fields.
* ゼロフィールドは0に設定されている必要があります。受信PEはゼロフィールドである必要がある必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | MAC Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ (6 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | IP Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EVPN MAC/IP Sub-TLV Format
図1：EVPN MAC/IP Sub-TLV形式
The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) associated with the MAC/IP Advertisement route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.
MPLSエコーリクエストは、Egress PEおよびMPLSトランスポートラベルによって発表されたMAC/IP広告ルートに関連付けられたEVPN MPLSラベルを使用して、EVPN MPLSラベルを使用してEVPN MPLSラベルを使用して送信され、Egress PEに到達します。
In EVPN, the MAC/IP Advertisement route has multiple uses and is used for the following cases:
EVPNでは、MAC/IP広告ルートには複数の用途があり、次の場合に使用されます。
* This route with only a MAC address and MPLS Label1 is used for populating MAC-VRF and performing MAC forwarding.
* MACアドレスとMPLS label1のみを備えたこのルートは、MAC-VRFの輸送とMAC転送の実行に使用されます。
* This route with MAC and IP addresses and only MPLS Label1 is used for populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for performing MAC forwarding.
* MACおよびIPアドレスとMPLS Label1のみを使用したこのルートは、MAC-VRFとARP/NDの両方のテーブル（ARP抑制用）の両方の両方の人間とMAC転送の実行に使用されます。
* This route with MAC and IP addresses and both MPLS Label1 and Label2 is used for populating MAC-VRF and IP-VRF tables as well as for both MAC and IP forwarding in the case of symmetric Integrated Routing and Bridging (IRB).
* MACおよびIPアドレスを備えたこのルート、およびMPLS LABEL1とLABEL2の両方が、対称統合ルーティングとブリッジング（IRB）の場合のMAC-VRFテーブルとIP-VRFテーブルとIP-VRFの両方のテーブルの居住に使用されます。
When an MPLS Echo Request is sent by an ingress PE, the contents of the Echo Request and the egress PE mode of operation (i.e., IRB mode or L2 mode) along with EVPN MPLS label of the packet determine which of the three cases above this Echo Request is for. When the egress PE receives the EVPN MAC/IP sub-TLV containing only the MAC address, the egress PE validates the MAC state and forwarding. When the egress PE receives the EVPN MAC/IP sub-TLV containing both MAC and IP addresses and if the EVPN label points to a MAC-VRF, then the egress PE validates the MAC state and forwarding. If the egress PE is not configured in symmetric IRB mode, it also validates ARP/ND state. However, if the EVPN label points to an IP-VRF, then the egress PE validates IP state and forwarding. Any other combinations (e.g., the egress PE receiving the EVPN MAC/IP sub-TLV containing only the MAC address but with the EVPN label pointing to an IP-VRF) should be considered invalid, and the egress PE should send an Echo Reply with the appropriate Return Code to the ingress PE.
MPLSエコーリクエストがイングレスPEによって送信されると、エコーリクエストの内容と出口PE操作モード（つまり、IRBモードまたはL2モード）とパケットのEVPN MPLSラベルが、この3つのケースのどれが上記の3つのケースを上回るかを決定します。エコーリクエストは次のとおりです。出力PEがMACアドレスのみを含むEVPN MAC/IP SUB-TLVを受信すると、出力PEはMAC状態と転送を検証します。出力PEがMACアドレスとIPアドレスの両方を含むEVPN MAC/IP SUB-TLVを受信し、EVPNラベルがMAC-VRFを指している場合、出力PEはMAC状態と転送を検証します。出力PEが対称IRBモードで構成されていない場合、ARP/nd状態も検証します。ただし、EVPNラベルがIP-VRFを指している場合、出力PEはIP状態と転送を検証します。その他の組み合わせ（たとえば、MACアドレスのみを含むEVPN MAC/IP SUB-TLVを受信する出力PEは、EVPNラベルがIP-VRFを指す）と見なされる必要があり、出力PEはエコーの返信を送信する必要があります。Ingress PEへの適切な返品コード。
The fields of the EVPN Inclusive Multicast sub-TLV are based on the EVPN Inclusive Multicast Tag route defined in Section 7.3 of [RFC7432]. This TLV is included in the Echo Request sent to the EVPN peer PE by the originator of the request to verify the multicast connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.
EVPNインクルーシブマルチキャストサブTLVのフィールドは、[RFC7432]のセクション7.3で定義されているEVPN包括的マルチキャストタグルートに基づいています。このTLVは、EVPNおよびPBB-EVPNネットワークのピアPEのマルチキャスト接続状態を検証するために、リクエストの発信元からEVPNピアPEに送信されたECHOリクエストに含まれています。
The EVPN Inclusive Multicast sub-TLV has the format shown in Figure 2. The fields of this sub-TLV should be set according to the following, which is consistent with [RFC7432] and [RFC7623]:
EVPNインクルーシブマルチキャストSub-TLVには、図2に示す形式があります。このサブTLVのフィールドは、[RFC7432]および[RFC7623]と一致する以下に従って設定する必要があります。
* The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE.
* Route Distinguisher（RD）フィールドは10オクテットフィールドであり、ピアPEのMAC-VRFのRDに設定されています。
* For EVPN, the Ethernet Tag ID field can be set to 0 or a valid VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of this field is set to the Service Instance Identifier (I-SID) value as per Section 5.3 of [RFC7623].
* EVPNの場合、EthernetタグIDフィールドは、EVPN VLAN対応バンドルサービス[RFC7432]の0または有効なVLAN IDに設定できます。PBB-EVPNの場合、このフィールドの値は、[RFC7623]のセクション5.3に従って、サービスインスタンス識別子（I-SID）値に設定されます。
* The IP Addr Len field specifies the length of the Originating Router's IP Addr field in bits and is set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
* IP addr lenフィールドは、BITSで発生するルーターのIP ADDRフィールドの長さを指定し、IPv4アドレスの場合は32、IPv6アドレスでは128に設定されています。
* The Originating Router's IP Addr field is set to the IPv4 or IPv6 address of the peer PE.
* 発生するルーターのIP ADDRフィールドは、ピアPEのIPv4またはIPv6アドレスに設定されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Addr Len | |
+-+-+-+-+-+-+-+ |
~ Originating Router's IP Addr ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EVPN Inclusive Multicast Sub-TLV Format
図2：EVPNインクルーシブマルチキャストサブTLV形式
BUM traffic can be sent using ingress replication or P2MP P-tree in EVPN and PBB-EVPN networks. When using ingress replication, the Echo Request is sent using a label stack of [Transport label, Inclusive Multicast label] to each egress PE participating in EVPN or PBB-EVPN. The Inclusive Multicast label is the downstream-assigned label announced by the egress PE to which the Echo Request is being sent. The Inclusive Multicast label is the inner label in the MPLS label stack.
EVPNおよびPBB-EVPNネットワークでのIngressレプリケーションまたはP2MP P-Treeを使用して、Bumトラフィックを送信できます。Ingressレプリケーションを使用する場合、ECHO要求は、EVPNまたはPBB-EVPNに参加する各出力PEに[トランスポートラベル、包括的マルチキャストラベル]のラベルスタックを使用して送信されます。包括的マルチキャストラベルは、Echoリクエストが送信されている出力PEによって発表されたダウンストリーム割り当てのラベルです。包括的マルチキャストラベルは、MPLSラベルスタックの内側ラベルです。
When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent using a P2MP P-tree transport label for the Inclusive P-tree arrangement or using a label stack of [P2MP P-tree Transport label, upstream-assigned EVPN Inclusive Multicast label] for the Aggregate Inclusive P2MP P-tree arrangement as described in Section 6.
EVPNまたはPBB-EVPNでP2MP P-Treeを使用する場合、ECHO要求は、包括的Pツリー配置のためにP2MP P-Treeトランスポートラベルを使用して送信されます。セクション6で説明されているように、Aggregate Inclusive P2MP P-Tree配置用のEVPN INCLUSIVE MULTICASTラベル]。
In an EVPN network, to emulate traffic coming from a multihomed site, an additional EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV and an ESI Split Horizon Group MPLS label as the bottom label are also included in the Echo Request packet. When using P2MP P-tree, the ESI Split Horizon Group MPLS label is upstream assigned. Please see Section 6.2.2 for operations using P2MP P-trees.
EVPNネットワークでは、マルチホームサイトからのトラフィックをエミュレートするために、ターゲットFECスタックTLVに追加のEVPNイーサネットA-DサブTLVと、ボトムラベルがECHOリクエストパケットにも含まれているため、ESIスプリットホライゾングループMPLSラベルが含まれています。P2MP P-Treeを使用する場合、ESIスプリットホライズングループMPLSラベルが上流に割り当てられます。P2MP P-Treeを使用した操作については、セクション6.2.2を参照してください。
The fields in the EVPN Ethernet A-D sub-TLV are based on the EVPN Ethernet A-D route advertisement defined in Section 7.1 of [RFC7432]. The EVPN Ethernet A-D sub-TLV only applies to EVPN.
EVPNイーサネットA-DサブTLVのフィールドは、[RFC7432]のセクション7.1で定義されているEVPNイーサネットA-Dルート広告に基づいています。EVPNイーサネットA-DサブTLVは、EVPNにのみ適用されます。
The EVPN Ethernet A-D sub-TLV has the format shown in Figure 3. The fields of this sub-TLV should be set according to the following, which is consistent with [RFC7432]:
EVPNイーサネットA-D Sub-TLVには、図3に示す形式があります。このサブTLVのフィールドは、[RFC7432]と一致する以下に従って設定する必要があります。
* The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE. Please see Section 4.3.2 for the case when a per-ES A-D route is announced with different RDs.
* Route Distinguisher（RD）フィールドは10オクテットフィールドであり、ピアPEのMAC-VRFのRDに設定されています。異なるRDSでPER-ES A-Dルートが発表された場合の場合は、セクション4.3.2を参照してください。
* The Ethernet Tag ID field can be 0, MAX-ET, or a valid VLAN ID as described in Section 4.3.1.
* イーサネットタグIDフィールドは、セクション4.3.1で説明されているように、0、MAX-ET、または有効なVLAN IDです。
* The Ethernet Segment Identifier field is a 10-octet field and is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES.
* イーサネットセグメント識別子フィールドは10オクテットフィールドであり、単一給屋の場合は0に設定されています。
* The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field.
* ゼロフィールドは0に設定されている必要があります。受信PEは、ゼロフィールドである必要がある必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EVPN Ethernet A-D Sub-TLV Format
図3：EVPNイーサネットA-DサブTLV形式
The EVPN Ethernet A-D sub-TLV can be sent in the context of per-ES or per-EVI. When an operator performs a connectivity check for the BUM L2 service, an Echo Request packet is sent and MAY contain the EVPN Ethernet A-D sub-TLV to emulate traffic coming from a multihomed site. In this case, the EVPN Ethernet A-D sub-TLV is added in the per-ES context. When an Echo Request packet is sent for the connectivity check for EVPN Aliasing state, the context for the EVPN Ethernet A-D sub-TLV is per-EVI.
EVPNイーサネットA-DサブTLVは、Per-ESまたはPER-EVIのコンテキストで送信できます。オペレーターがBum L2サービスの接続チェックを実行すると、エコーリクエストパケットが送信され、EVPNイーサネットA-DサブTLVが含まれて、マルチホームサイトからのトラフィックをエミュレートすることができます。この場合、EVPNイーサネットA-DサブTLVがPER-ESコンテキストに追加されます。EVPNエイリアシング状態の接続チェック用にエコーリクエストパケットが送信されると、EVPNイーサネットA-D Sub-TLVのコンテキストはEVIごとです。
The Ethernet Tag field value in the EVPN Ethernet A-D sub-TLV MUST be set according to the context:
EVPNイーサネットA-DサブTLVのイーサネットタグフィールド値は、コンテキストに従って設定する必要があります。
* For the per-ES context, the Ethernet Tag field in the sub-TLV MUST be set to the reserved MAX-ET value [RFC7432].
* PER-ESコンテキストでは、Sub-TLVのイーサネットタグフィールドを予約済みのMAX-ET値[RFC7432]に設定する必要があります。
* For the per-EVI context, the Ethernet Tag field in the sub-TLV MUST be set to the non-reserved value.
* EVIごとのコンテキストでは、Sub-TLVのイーサネットタグフィールドは、非返済値に設定する必要があります。
Section 8.2 of [RFC7432] specifies that a per-ES EVPN A-D route for a given multihomed ES may be advertised more than once with different RD values because many EVIs may be associated with the same ES and Route Targets for all these EVIs may not fit in a single BGP Update message. In this case, the RD value used in the EVPN Ethernet A-D sub-TLV MUST be the RD value received for the EVI in the per-ES EVPN A-D route.
[RFC7432]のセクション8.2は、多くのEVIがこれらすべてのEVIの同じESおよびルートターゲットに関連付けられている可能性があるため、特定のマルチホームESのPER-ESEVPN A-Dルートが異なるRD値で複数回宣伝される可能性があることを指定しています。単一のBGP更新メッセージ。この場合、EVPNイーサネットA-DサブTLVで使用されるRD値は、PER-ES EVPN A-DルートのEVIのRD値でなければなりません。
LSP Ping can also be used to detect data plane failures for the EVPN VPWS described in [RFC8214]. The Echo Request packet carries the EVPN Ethernet A-D sub-TLV with fields populated from the EVPN Ethernet A-D per-EVI route announced by the egress PE for the EVPN VPWS under test. The Echo Request is sent by the ingress PE using the EVPN MPLS label associated with the EVPN Ethernet A-D route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.
LSP Pingは、[RFC8214]に記載されているEVPN VPWのデータプレーン障害を検出するためにも使用できます。Echo Request Packetは、EVPN Ethernet A-D Sub-TLVを搭載し、テスト中のEVPN VPWの出口PEが発表したEVPNイーサネットA-D PE-EVIルートから入力されます。エコー要求は、出口PEおよびMPLSトランスポートラベルによって発表されたEVPNイーサネットA-Dルートに関連付けられたEVPN MPLSラベルを使用して、EVPN MPLSラベルを使用して、出口PEによって送信されます。
The egress PE processes the Echo Request packet and performs checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and responds according to processing rules in [RFC8029]. The egress PE can identify that the Echo Request is for the EVPN VPWS instance as EVI (identified by the RD) for EVPN VPWS is different from EVI assigned for EVPN. The egress PE will use the information from the EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV and validate the VLAN state for the EVPN VPWS under test. For the success case, the egress PE will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>").
出力PEは、[RFC8029]のセクション4.4に記載されているように、ターゲットFECスタックTLVに存在するEVPNイーサネットA-DサブTLVのチェックをエコーリクエストパケットを処理し、[RFC8029]の処理ルールに従って応答します。EVPN VPWSのEVI（RDで識別）がEVPNに割り当てられたEVIとは異なるため、EVPN VPWSインスタンスのECHO要求がEVPN VPWSインスタンスのECHO要求がEVPN VPWSインスタンスのものであることを識別できます。出力PEは、ターゲットFECスタックTLVのEVPNイーサネットA-DサブTLVからの情報を使用し、テスト中のEVPN VPWのVLAN状態を検証します。成功事例の場合、出力PEは戻りコード3で返信します（「Replyingルーターは、Stack-Depth <RSC>のFECの出力です」）。
The EVPN IP Prefix sub-TLV identifies the IP prefix for an EVI under test at a peer PE.
EVPN IPプレフィックスSub-TLVは、ピアPEでテスト中のEVIのIPプレフィックスを識別します。
The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix route (RT-5) advertisement defined in [RFC9136]. This sub-TLV only applies to EVPN.
EVPN IPプレフィックスSub-TLVフィールドは、[RFC9136]で定義されたIPプレフィックスルート（RT-5）広告から派生しています。このSub-TLVはEVPNにのみ適用されます。
The EVPN IP Prefix sub-TLV has the format shown in Figure 4. The total length (not shown) of this sub-TLV MUST be either 32 bytes (if IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carried). The IP prefix and gateway IP address MUST be from the same IP address family, as described in Section 3.1 of [RFC9136].
EVPN IPプレフィックスSub-TLVには、図4に示す形式があります。このサブTLVの合計長（図示せず）は、32バイト（IPv4アドレスが伝達される場合）または56バイト（IPv6アドレスが運ばれている場合）でなければなりません。[RFC9136]のセクション3.1で説明されているように、IPプレフィックスとゲートウェイIPアドレスは、同じIPアドレスファミリからのものでなければなりません。
The fields of the EVPN IP Prefix sub-TLV should be set according to the following, which is consistent with [RFC9136]:
EVPN IPプレフィックスSUB-TLVのフィールドは、[RFC9136]と一致する以下に従って設定する必要があります。
* The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the IP-VRF on the peer PE.
* Route Distinguisher（RD）フィールドは10オクテットフィールドであり、ピアPEのIP-VRFのRDに設定されています。
* The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle service [RFC7432].
* イーサネットタグIDフィールドは、EVPN VLAN-AWAREバンドルサービス[RFC7432]の0または有効なVLAN IDにすることができます。
* The Ethernet Segment Identifier field is a 10-octet field and is set to a valid ESI ID if the ESI is used as an Overlay Index as per Section 3.1 of [RFC9136]. Otherwise, the Ethernet Segment Identifier field is set to 0.
* イーサネットセグメント識別子フィールドは10オクテットフィールドであり、[RFC9136]のセクション3.1に従ってESIがオーバーレイインデックスとして使用される場合、有効なESI IDに設定されます。それ以外の場合、イーサネットセグメント識別子フィールドは0に設定されています。
* The IP Prefix Len field specifies the number of bits in the IP Prefix field. It is set to a value between 0 and 32 for IPv4 or between 0 to 128 for IPv6.
* IPプレフィックスLENフィールドは、IPプレフィックスフィールドのビット数を指定します。IPv4の場合は0〜32、IPv6の場合は0〜128の間で設定されます。
* The IP Prefix field is set to a 4-octet IPv4 address (with trailing 0 bits to make 32 bits in all) or a 16-octet IPv6 address (with trailing 0 bits to make 128 bits in all). The address family of this field is inferred from the sub-TLV length field, as discussed above.
* IPプレフィックスフィールドは、4-OCTET IPv4アドレス（すべての32ビットを作成するために0ビットを走る）または16-OCTET IPv6アドレス（すべてで128ビットを作成するために0ビットを操縦する）に設定されています。上記のように、このフィールドの住所ファミリは、サブTLV長さフィールドから推測されます。
* The Gateway (GW) IP Address field is set to a 4-octet IPv4 address or a 16-octet IPv6 address if it's used as an Overlay Index for the IP prefixes. If the GW IP Address is not being used, it must be set to 0 as described in Section 3.1 of [RFC9136]. The address family of this field is inferred from the sub-TLV length field, as discussed above.
* Gateway（GW）IPアドレスフィールドは、IPプレフィックスのオーバーレイインデックスとして使用されている場合、4-OCTET IPv4アドレスまたは16-OCTET IPv6アドレスに設定されています。GW IPアドレスが使用されていない場合は、[RFC9136]のセクション3.1で説明されているように0に設定する必要があります。上記のように、このフィールドの住所ファミリは、サブTLV長さフィールドから推測されます。
* The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field.
* ゼロフィールドは0に設定されている必要があります。受信PEは、ゼロフィールドである必要がある必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier |
| (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | IP Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Prefix (4 or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ GW IP Address (4 or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EVPN IP Prefix Sub-TLV Format
図4：EVPN IPプレフィックスサブTLV形式
The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) associated with the IP Prefix route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.
MPLSエコーリクエストは、出口PEおよびMPLSトランスポートラベルによって発表されたIPプレフィックスルートに関連付けられたEVPN MPLSラベルを使用して、EVPN MPLSラベルを使用して、出口PEに到達するために送信されます。
The MPLS Echo Request IP/UDP packets MUST be encapsulated with the Transport and EVPN label(s) followed by the GAL [RFC5586], which is the bottommost label. The GAL is followed by a G-ACh header carrying the IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 and IPv6 channels are defined in the "Generic Associated Channel (G-ACh) Parameters" IANA registry.
MPLSエコーリクエストIP/UDPパケットは、TransportおよびEVPNラベル（s）に続いて、BottommostラベルであるGal [RFC5586]を使用してカプセル化する必要があります。GALの後に、IPv4（0x0021）またはIPv6（0x0057）チャネルタイプを運ぶG-achヘッダーが続きます。IPv4およびIPv6チャネルのコードポイントは、「一般的な関連チャネル（G-CACH）パラメーター」IANAレジストリで定義されています。
Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to PE1 and PE2. Assume that PE1 announced a MAC route with RD 192.0.2.1:00 and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. Similarly, PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16002.
図5は、PBB-EVPNネットワークの例です。CE1は、PE1とPE2にデュアルホームされています。PE1がRD 192.0.2.1:00およびB-MAC 00-AA-00-BB-00-CCを搭載したMACルートを発表し、EVI 10のMPLSラベル16001で発表したと仮定します。同様に、PE2はRD 203.0.113.2のMACルートを発表しました。：00およびB-MAC 00-AA-00-BB-00-CCおよびMPLSラベル16002。
On PE3, when an operator performs a connectivity check for the B-MAC address 00-AA-00-BB-00-CC on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN MAC/IP sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN label = 16001, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE1, PE1 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The PE1 will process the packet and perform checks for the EVPN MAC/IP sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond according to the processing rules in [RFC8029].
PE3では、オペレーターがPE1でB-MACアドレス00-AA-00-BB-00-CCの接続チェックを実行すると、演算子はEVPN MAC/IPサブサブサブを含むターゲットFECスタックTLVでLSP Pingリクエストを開始します。-tlv in the echo request packet。エコーリクエストパケットは、{トランスポートラベルとともに送信され、PE1、EVPNラベル= 16001、GAL} MPLSラベルスタックおよびIP ACHチャネルヘッダーに到達します。エコー要求パケットがPE1に到達すると、PE1はGALとIP ACHチャネルヘッダーを使用して、パケットがIPv4またはIPv6 OAMパケットであるかどうかを判断します。PE1は、[RFC8029]のセクション4.4で説明されているように、ターゲットFECスタックTLVに存在するEVPN MAC/IP SUB-TLVのパケットを処理し、[RFC8029]のセクション4.4で説明し、[RFC8029]の処理ルールに従って応答します。
+-----------------+
| |
| |
+----+ AC1 +-----+ +-----+ +----+
| CE1|------| | | PE3 |-----| CE2|
+----+\ | PE1 | IP/MPLS | | +----+
\ +-----+ Network +-----+
\ | |
AC2\ +-----+ |
\ | | |
\| PE2 | |
+-----+ |
| |
+-----------------+
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 5: PBB-EVPN Network
図5：PBB-EVPNネットワーク
Similarly, on PE3, when an operator performs a connectivity check for the B-MAC address 00-AA-00-BB-00-CC on PE2, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN MAC/IP sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {MPLS Transport label(s) to reach PE2, EVPN label = 16002, GAL} MPLS label stack and IP ACH Channel header.
同様に、PE3では、オペレーターがPE2でB-MACアドレス00-AA-00-BB-00-CCの接続チェックを実行するとき、演算子はEVPN MAC/を含むターゲットFECスタックTLVでLSP Pingリクエストを開始します。Echo Request PacketのIP Sub-TLV。エコーリクエストパケットは、{MPLSトランスポートラベルとともに送信され、PE2、EVPNラベル= 16002、GAL} MPLSラベルスタックおよびIP ACHチャネルヘッダーに到達します。
LSP Ping operations for unicast data plane connectivity checks in EVPN are similar to those described above for PBB-EVPN, except that the checks are for C-MAC addresses instead of B-MAC addresses.
EVPNのユニキャストデータプレーン接続のLSP Ping操作は、B-MACアドレスの代わりにチェックがC-MACアドレス用であることを除いて、PBB-EVPNについて上記のものと類似しています。
In EVPN networks, an operator can also perform a MAC state test using an aliasing label for the MAC to verify the MAC state on the egress multihoming PE that did not learn the MAC from the multihomed CE on a local ESI but has announced Ethernet A-D per-EVI and per-ESI routes for the ESI. This is due to the fact that MAC state on multihoming PEs that did not learn the MAC locally get created from EVPN MAC/IP route advertisement from the multihoming PE that has learned the CE's MAC address locally.
EVPNネットワークでは、オペレーターはMACのエイリアシングラベルを使用してMAC状態テストを実行して、ローカルESIのマルチホームCEからMACを学習しなかったが、イーサネットA-DあたりのイーサネットA-Dを発表した出力マルチホームPEでMAC状態を検証することもできます。-ESIのEVIおよびPER-ESIルート。これは、CEのMACアドレスをローカルで学習したマルチホミングPEからEVPN Mac/IPルート広告から局所的に作成されるMacを局所的に学習しなかったMac Mac PESのMAC状態です。
Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 192.0.2.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type set to ingress replication, and downstream-assigned Inclusive Multicast MPLS label 17001. Similarly, PE2 announced an Inclusive Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type set to ingress replication, and downstream-assigned Inclusive Multicast MPLS label 17002.
PE1がEVI 10の包括的なマルチキャストルートを発表したと仮定します。RD192.0.2.1：00、イーサネットタグ（ISID 10）、PMSIトンネル属性トンネルタイプが複製を侵入するように設定され、ダウンストリーム割り当て包括的マルチキャストMPLラベル17001。同様に、PE2は発表しました。RD 203.0.113.2：00、イーサネットタグ（ISID 10）、PMSIトンネル属性トンネルタイプが複製に設定されたPMSIトンネル属性タイプ、下流に割り当てられた包括的マルチキャストMPLSラベル17002を備えた包括的なマルチキャストルート。
Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 44dd.5500.
CE1がPE1とPE2にデュアルホームされていることを考えると、PE1はESI 11AA.22BB.33ccに対応するポートのISID 10のDFであると仮定します。44dd.5500。
When an operator at PE3 initiates a connectivity check for the Inclusive Multicast on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN Inclusive Multicast label = 17001, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE1, PE1 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The packet will have the EVPN Inclusive Multicast label. PE1 will process the packet and perform checks for the EVPN Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond according to the processing rules in [RFC8029]. For the success case, PE1 will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>").
PE3のオペレーターがPE1の包括的なマルチキャストの接続チェックを開始すると、演算子はECHOリクエストパケットにEVPN包括的マルチキャストサブTLVを含むターゲットFECスタックTLVでLSP Pingリクエストを開始します。エコーリクエストパケットは、{トランスポートラベルとともに送信され、PE1、EVPNインクルーシブマルチキャストラベル= 17001、GAL} MPLSラベルスタックおよびIP ACHチャネルヘッダーに到達します。エコー要求パケットがPE1に到達すると、PE1はGALとIP ACHチャネルヘッダーを使用して、パケットがIPv4またはIPv6 OAMパケットであるかどうかを判断します。パケットには、EVPNを含むマルチキャストラベルがあります。PE1は、[RFC8029]のセクション4.4で説明されているように、ターゲットFECスタックTLVに存在するEVPNインクルーシブマルチキャストサブTLVのパケットを処理し、[RFC8029]の処理ルールに従って応答します。サクセスケースの場合、PE1は返されるコード3で返信します（「Replying Routerは、Stack-Depth <RSC>のFECの出口です」）。
Similarly, an operator at PE3 may initiate an LSP Ping to PE2 with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE2, EVPN Inclusive Multicast label = 17002, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The processing on PE2 will be similar to that on PE1 as described above. For the success case, PE2 will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") as per [RFC8029].
同様に、PE3のオペレーターは、ECHO要求パケットにEVPN包括的マルチキャストサブTLVを含むターゲットFECスタックTLVを使用して、LSP Ping to PE2を開始する場合があります。エコーリクエストパケットは、{トランスポートラベル（s）とともに送信され、PE2、EVPNインクルーシブマルチキャストラベル= 17002、GAL} MPLSラベルスタック、IP ACHチャネルヘッダーに到達します。エコー要求パケットがPE2に到達すると、PE2はGALとIP ACHチャネルヘッダーを使用して、パケットがIPv4またはIPv6 OAMパケットであるかどうかを判断します。PE2の処理は、上記のようにPE1の処理と同様です。サクセスケースの場合、PE2は[RFC8029]に従って、RETURN CODE 3（「Replying RouterはStack-Depth <RSC> "のFECの出口です）で返信します。
In an Echo Request packet for EVPN, a combination of an EVPN Ethernet A-D sub-TLV and the associated MPLS Split Horizon label, immediately preceding the GAL in the MPLS label stack, may be used to emulate traffic coming from a multihomed site. The Split Horizon label is used by leaf PE(s) attached to the same multihomed site to prevent forwarding of packets back to the multihomed site. If the behavior on a leaf PE is to not forward the packet to the multihomed site on the ESI identified by the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, the PE will reply with Return Code 37 (see Section 8) and drop the BUM packets on the ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV because of the Split Horizon Group filtering.
EVPNのエコー要求パケットでは、EVPNイーサネットA-DサブTLVと、MPLSラベルスタックのGALの直前の関連MPLS分割ホリズンラベルの組み合わせを使用して、マルチホームサイトからのトラフィックをエミュレートするために使用できます。スプリットホライズンラベルは、マルチホームサイトへのパケットの転送を防ぐために、同じマルチホームサイトに接続されたリーフPEで使用されます。リーフPEの動作が、スプリットホライズンフィルタリングのためにEVPNイーサネットA-DサブTLVによって識別されたESI上のマルチホームサイトにパケットを転送しないことである場合、PEは戻りコード37（セクション8を参照）で応答し、ドロップしますスプリットホライズングループフィルタリングのため、EVPNイーサネットA-DサブTLVで受信したESIに対応するES上のバムパケット。
Both Inclusive P-tree and Aggregate Inclusive P-tree can be used in EVPN or PBB-EVPN networks.
包括的Pツリーと凝集体の両方の包括的Pツリーは、EVPNまたはPBB-EVPNネットワークで使用できます。
When using an Inclusive P-tree arrangement, the P2MP P-tree transport label itself is used to identify the L2 service associated with the Inclusive Multicast route. This L2 service could be a Customer Bridge or a Provider Backbone Bridge.
包括的なPツリー配置を使用する場合、P2MP P-Treeトランスポートラベル自体を使用して、包括的マルチキャストルートに関連するL2サービスを識別します。このL2サービスは、カスタマーブリッジまたはプロバイダーバックボーンブリッジである可能性があります。
For an Inclusive P-tree arrangement, when an operator performs a connectivity check for the multicast L2 service, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent over P2MP LSP with the {P2MP P-tree Transport label, GAL} MPLS label stack and IP ACH Channel header.
包括的なPツリー配置の場合、オペレーターがマルチキャストL2サービスの接続チェックを実行するとき、オペレーターはEchoリクエストパケットにEVPN包括的マルチキャストサブTLVを含むターゲットFECスタックTLVでLSP Pingリクエストを開始します。エコーリクエストパケットは、{P2MP P-Tree Transportラベル、GAL} MPLSラベルスタック、IP ACHチャネルヘッダーを使用してP2MP LSPを介して送信されます。
When using an Aggregate Inclusive P-tree arrangement, a PE announces an upstream-assigned MPLS label along with the P-tree ID, so both the P2MP P-tree MPLS transport label and the upstream MPLS label can be used to identify the L2 service.
総包括的Pツリー配置を使用する場合、PEはP-Tree IDとともに上流に割り当てられたMPLSラベルを発表するため、P2MP P-Tree MPLSトランスポートラベルとアップストリームMPLSラベルの両方を使用してL2サービスを識別できます。。
For an Aggregate Inclusive P-tree arrangement, when an operator performs a connectivity check for the multicast L2 service, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent over P2MP LSP using the IP-ACH Control channel with the {P2MP P-tree Transport label, EVPN upstream-assigned Multicast label, GAL} MPLS label stack and IP ACH Channel header.
総包括的なPツリー配置の場合、オペレーターがマルチキャストL2サービスの接続チェックを実行するとき、オペレーターはECHOリクエストパケットにEVPN包括的マルチキャストSub-TLVを含むターゲットFECスタックTLVでLSP Pingリクエストを開始します。Echo Request Packetは、{P2MP P-Tree Transportラベル、EVPNアップストリーム割り当てマルチキャストラベル、GAL} MPLSラベルスタック、IP ACHチャネルヘッダーを使用して、IP-achコントロールチャネルを使用してP2MP LSPを介して送信されます。
The leaf PE(s) of the P2MP P-tree will process the packet and perform checks for the EVPN Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond according to the processing rules in [RFC8029]. For the success case, the leaf PE will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>").
P2MP P-TreeのリーフPE（s）は、[RFC8029]のセクション4.4で説明されているように、ターゲットFECスタックTLVに存在するEVPN包括的マルチキャストSub-TLVのパケットを処理し、チェックを実行し、処理ルールに従って応答します[RFC8029]。成功の場合、Leaf PEは返されるコード3で返信します（「Replyingルーターは、Stack-Depth <RSC>のFECの出口です」）。
In an Echo Request packet for EVPN, a combination of an EVPN Ethernet A-D sub-TLV and the associated MPLS Split Horizon label, immediately preceding the GAL in the MPLS label stack, may be used to emulate traffic coming from a multihomed site. When using P2MP P-tree, the Split Horizon label is upstream assigned and is received by all the leaf PEs of the P2MP P-tree. The Split Horizon label is used by leaf PE(s) attached to the same multihomed site so that packets will not be forwarded back to the multihomed site. If the behavior on a leaf PE is to not forward the packet to the multihomed site on the ESI in the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, the PE will reply with Return Code 37 (see Section 8) and drop the BUM packets on the ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV because of the Split Horizon Group filtering. If the leaf PE does not have the ESI identified in the EVPN Ethernet A-D sub-TLV, the PE MAY reply with Return Code 38 (see Section 8), and the BUM packets are forwarded because there is no ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV.
EVPNのエコー要求パケットでは、EVPNイーサネットA-DサブTLVと、MPLSラベルスタックのGALの直前の関連MPLS分割ホリズンラベルの組み合わせを使用して、マルチホームサイトからのトラフィックをエミュレートするために使用できます。P2MP P-Treeを使用する場合、スプリットホライズンラベルは上流に割り当てられ、P2MP P-Treeのすべての葉ペスによって受信されます。スプリットホライズンラベルは、同じマルチホームサイトに接続されたリーフPEで使用されているため、パケットがマルチホームサイトに転送されません。リーフPEの動作が、スプリットホライズンフィルタリングのためにEVPNイーサネットA-DサブTLVのESI上のマルチホームサイトにパケットを転送しないことである場合、PEは戻りコード37（セクション8を参照）で応答し、ドロップします。Split Horizonグループフィルタリングのため、EVPNイーサネットA-DサブTLVで受信したESIに対応するES上のバムパケット。葉のPEがEVPNイーサネットA-DサブTLVでESIを識別していない場合、PEは返されるコード38（セクション8を参照）で応答し、BUMパケットは、で受信したESIに対応するESがないため転送されますEVPNイーサネットA-DサブTLV。
The procedures described in [RFC6425] for preventing congestion of Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a single egress node (P2MP Responder Identifier TLV with either the IPv4 Node Address P2MP Responder sub-TLV or the IPv6 Node Address P2MP Responder sub-TLV) can be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees for BUM traffic.
[RFC6425]で説明されている手順エコー応答の輻輳を防止し（エコージッターTLV）、単一の出力ノード（P2MPレスポンダー識別子TLVへのエコー応答を制限する手順（IPv4ノードアドレスアドレスP2MP Responder sub-TLV）またはIPV6ノードアドレスP2MPResponder sub-tlv）は、BumトラフィックにP2MP P-Treeを使用する場合、EVPNおよびPBB-EVPNのLSP pingに適用できます。
Assume PE1 announced an Ethernet A-D per-EVI route with the ESI set to CE1 system ID and MPLS label 19001. Additionally, assume PE2 announced an Ethernet A-D per-EVI route with the ESI set to CE1 system ID and MPLS label 19002.
PE1がESIをCE1システムIDおよびMPLSラベル19001に設定したイーサネットA-D PER-EVIルートを発表したと仮定します。さらに、PE2がESIをCE1システムIDおよびMPLSラベル19002に設定したイーサネットA-D PER-EVIルートを発表したと仮定します。
At PE3, when an operator performs a connectivity check for the aliasing aspect of the EVPN Ethernet A-D route on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Ethernet A-D sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN Ethernet A-D label 19001, GAL} MPLS label stack and IP ACH Channel header.
PE3では、演算子がPE1のEVPNイーサネットA-Dルートのエイリアシング側面の接続チェックを実行すると、演算子はECHOリクエストパケットにEVPNイーサネットA-DサブTLVを含むターゲットFECスタックTLVを使用してLSP Pingリクエストを開始します。エコーリクエストパケットは、{トランスポートラベルとともに送信され、PE1、EVPNイーサネットA-Dラベル19001、GAL} MPLSラベルスタック、IP ACHチャネルヘッダーに到達します。
When PE1 receives the packet, it will process the packet and perform checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond according to the processing rules in [RFC8029].
PE1がパケットを受信すると、[RFC8029]のセクション4.4で説明されているように、ターゲットFECスタックTLVに存在するEVPNイーサネットA-DサブTLVのパケットを処理し、[RFC8029]の処理ルールに従って応答します。
Assume PE1 in Figure 5 announced an IP Prefix route (RT-5) with an IP prefix reachable behind CE1 and MPLS label 20001. When an operator on PE3 performs a connectivity check for the IP prefix on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN IP Prefix sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN IP Prefix label 20001 } MPLS label stack.
図5のPE1が、CE1およびMPLSラベル20001の背後に到達可能なIPプレフィックスを備えたIPプレフィックスルート（RT-5）を発表したと仮定します。PE3のオペレーターがPE1のIPプレフィックスの接続チェックを実行すると、オペレーターはLSP Pingリクエストを開始します。ターゲットFECスタックTLVを使用して、ECHOリクエストパケットにEVPN IPプレフィックスSub-TLVを含みます。エコーリクエストパケットは、{トランスポートラベル（s）とともに送信され、PE1、EVPN IPプレフィックスラベル20001} MPLSラベルスタックに到達します。
When PE1 receives the packet, it will process the packet and perform checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond according to the processing rules in [RFC8029].
PE1がパケットを受信すると、[RFC8029]のセクション4.4で説明されているように、ターゲットFECスタックTLVに存在するEVPN IPプレフィックスSub-TLVのパケットを処理し、[RFC8029]の処理ルールに従って応答します。
This document does not introduce any new security considerations beyond those that apply in [RFC7432], [RFC7623], and [RFC6425]. Furthermore, the security considerations discussed in [RFC8029] apply to this document and need to be considered. As described in [RFC8029], these security considerations are:
このドキュメントでは、[RFC7432]、[RFC7623]、および[RFC6425]に適用されるもの以外の新しいセキュリティ上の考慮事項は導入されていません。さらに、[RFC8029]で議論されているセキュリティ上の考慮事項は、この文書に適用され、考慮する必要があります。[RFC8029]で説明されているように、これらのセキュリティ上の考慮事項は次のとおりです。
* A Denial-of-Service (DoS) attack by sending MPLS Echo Requests/ Replies to Label Switching Routers (LSRs) and thereby increasing their workload.
* MPLSエコーリクエスト/返信を送信することによるサービス拒否（DOS）攻撃により、スイッチングルーター（LSR）がラベル付けされ、それによってワークロードが増加します。
* Obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS Echo Requests and Replies.
* MPLSのリクエストと返信のスプーフィング、ハイジャック、リプレイ、または改ざんにより、MPLSデータプレーンの活性の状態を難読化します。
* Obtaining information about the network through an unauthorized source using an LSP Ping.
* LSP pingを使用して不正なソースを介してネットワークに関する情報を取得します。
There are mitigations described in [RFC8029]. The same mitigations can be applied to the LSP Ping procedures described in this document; thus, this document doesn't require additional security considerations beyond the ones described in [RFC8029].
[RFC8029]に記載されている緩和があります。このドキュメントで説明されているLSP ping手順にも同じ緩和を適用できます。したがって、このドキュメントは、[RFC8029]に記載されているものを超えた追加のセキュリティ上の考慮事項を必要としません。
This document does not introduce any new privacy concerns because these TLVs contain the same information that are present in data packets and EVPN routes.
これらのTLVには、データパケットとEVPNルートに存在する同じ情報が含まれているため、このドキュメントでは新しいプライバシーの懸念は導入されません。
This document defines four new sub-TLV types to be included in the Target FEC Stack TLV (TLV types 1, 16, and 21) [RFC9041] in Echo Request and Echo Reply messages in EVPN and PBB-EVPN networks.
このドキュメントでは、ECHOリクエストでターゲットFECスタックTLV（TLVタイプ1、16、および21）[RFC9041）に含まれる4つの新しいサブTLVタイプをEVPNおよびPBB-EVPNネットワークのエコー応答メッセージに定義します。
IANA has assigned the following values from the "Standards Action" (0-16383) range in the "Sub-TLVs for TLV Types 1, 16, and 21" subregistry within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）の「TLVS」レジストリ内の「TLVタイプ1、16、および21」のサブレジストリ内の「TLVタイプ1、16、および21」サブレジストリの「標準アクション」（0-16383）の範囲から次の値を割り当てました。ラベルスイッチ付きパス（LSP）pingパラメーター "名前スペース。
+==========+==============================+===========+
| Sub-Type | Sub-TLV Name | Reference |
+==========+==============================+===========+
| 42 | EVPN MAC/IP | RFC 9489 |
+----------+------------------------------+-----------+
| 43 | EVPN Inclusive Multicast | RFC 9489 |
+----------+------------------------------+-----------+
| 44 | EVPN Ethernet Auto-Discovery | RFC 9489 |
+----------+------------------------------+-----------+
| 45 | EVPN IP Prefix | RFC 9489 |
+----------+------------------------------+-----------+
Table 1
[RFC8029] defines values for the Return Code field of Echo Reply messages. This document defines two new Return Codes that SHOULD be included in the Echo Reply message by a PE in response to an Echo Request message in EVPN and PBB-EVPN networks.
[RFC8029]は、エコー応答メッセージのリターンコードフィールドの値を定義します。このドキュメントでは、EVPNおよびPBB-EVPNネットワークのエコーリクエストメッセージに応じて、PEでEcho Replyメッセージに含める必要がある2つの新しいリターンコードを定義します。
IANA has assigned the following values in the "Return Codes" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSPS）PINGパラメーター」という名前のスペースの「リターンコード」レジストリに次の値を割り当てました。
+=======+=============================================+===========+
| Value | Meaning | Reference |
+=======+=============================================+===========+
| 37 | Replying router is egress for the FEC at | RFC 9489 |
| | the stack depth. In addition, the BUM | |
| | packets are dropped on the ES corresponding | |
| | to the ESI received in the EVPN Ethernet | |
| | Auto-Discovery sub-TLV because of the Split | |
| | Horizon Group filtering. | |
+-------+---------------------------------------------+-----------+
| 38 | Replying router is egress for the FEC at | RFC 9489 |
| | the stack depth. In addition, the BUM | |
| | packets are forwarded because there is no | |
| | ES corresponding to the ESI received in the | |
| | EVPN Ethernet Auto-Discovery sub-TLV. | |
+-------+---------------------------------------------+-----------+
Table 2
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[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>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,
"Updating the MPLS Label Switched Paths (LSPs) Ping
Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
July 2021, <https://www.rfc-editor.org/info/rfc9041>.
[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 would like to thank Loa Andersson, Alexander Vainshtein, Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Éric Vyncke, Warren Kumari, Patrice Brissette, and Weiguo Hao for their valuable comments.
著者は、Loa Andersson、Alexander Vainshtein、Ron Sdayoor、Jim Guichard、Lars Eggert、John Scudder、Eric Vyncke、Warren Kumari、Patrice Brissette、およびWeiguo Haoに貴重なコメントに感謝したいと思います。
Parag Jain
Cisco
Canada
Email: paragj@cisco.com
Ali Sajassi
Cisco
United States of America
Email: sajassi@cisco.com
Samer Salam
Cisco
Canada
Email: ssalam@cisco.com
Sami Boutros
Ciena
United States of America
Email: sboutros@ciena.com
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com