[要約] RFC 9135は、Ethernet VPN (EVPN) 内での統合ルーティングとブリッジングを定義します。この技術は、異なるネットワークセグメント間での効率的なデータ転送と、拡張性の高いマルチキャストサービスを提供することを目的としています。主に、大規模なデータセンターやサービスプロバイダー環境での利用が想定されています。
Internet Engineering Task Force (IETF) A. Sajassi
Request for Comments: 9135 S. Salam
Category: Standards Track S. Thoria
ISSN: 2070-1721 Cisco Systems
J. Drake
Juniper
J. Rabadan
Nokia
October 2021
Integrated Routing and Bridging in Ethernet VPN (EVPN)
イーサネットVPN（EVPN）における統合ルーティングとブリッジング
Abstract
概要
Ethernet VPN (EVPN) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
イーサネットVPN（EVPN）は、テナントシステム間のサブネット内の接続のためのMPLS / IPネットワーク上で、物理的または仮想的になることができるエンドデバイスの間のMPLS / IPネットワークを介して拡張可能で柔軟なマルチホーム化VPNソリューションを提供します。ただし、EVPNのマルチホーム機能を維持しながら、これらのテナントシステムとエンドデバイスの間で動的で効率的なサブネット接続が必要とされているシナリオがあります。この文書では、そのような要件に対処するためにEVPNに基づく統合ルーティングおよびブリッジング（IRB）ソリューションについて説明します。
Status of This Memo
本文書の位置付け
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/rfc9135.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/rfc9135で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Requirements Language
3. EVPN PE Model for IRB Operation
4. Symmetric and Asymmetric IRB
4.1. IRB Interface and Its MAC and IP Addresses
4.2. Operational Considerations
5. Symmetric IRB Procedures
5.1. Control Plane - Advertising PE
5.2. Control Plane - Receiving PE
5.3. Subnet Route Advertisement
5.4. Data Plane - Ingress PE
5.5. Data Plane - Egress PE
6. Asymmetric IRB Procedures
6.1. Control Plane - Advertising PE
6.2. Control Plane - Receiving PE
6.3. Data Plane - Ingress PE
6.4. Data Plane - Egress PE
7. Mobility Procedure
7.1. Initiating a Gratuitous ARP upon a Move
7.2. Sending Data Traffic without an ARP Request
7.3. Silent Host
8. BGP Encoding
8.1. EVPN Router's MAC Extended Community
9. Operational Models for Symmetric Inter-Subnet Forwarding
9.1. IRB Forwarding on NVEs for Tenant Systems
9.1.1. Control Plane Operation
9.1.2. Data Plane Operation
9.2. IRB Forwarding on NVEs for Subnets behind Tenant Systems
9.2.1. Control Plane Operation
9.2.2. Data Plane Operation
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses
EVPN [RFC7432] provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems (TSs) and end devices that can be physical or virtual, where an IP subnet is represented by an EVPN instance (EVI) for a VLAN-based service or by an (EVI, VLAN) association for a VLAN-aware bundle service. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
EVPN [RFC7432]は、IPサブネットがEVPNインスタンスで表される、テナントシステム（TSS）とエンドデバイスの間のサブネット内の接続のためのMPLS / IPネットワークを介して拡張可能で柔軟なマルチホーム化されたVPNソリューションを提供します。VLANベースのサービスの場合、またはVLAN対応バンドルサービスのための（EVI、VLAN）の関連付け。ただし、EVPNのマルチホーム機能を維持しながら、これらのテナントシステムとエンドデバイスの間で動的で効率的なサブネット接続が必要とされているシナリオがあります。この文書では、そのような要件に対処するためにEVPNに基づく統合ルーティングおよびブリッジング（IRB）ソリューションについて説明します。
Inter-subnet communication is typically performed by centralized Layer 3 (L3) gateway (GW) devices, which enforce all inter-subnet communication policies and perform all inter-subnet forwarding. When two TSs belonging to two different subnets connected to the same Provider Edge (PE) wanted to communicate with each other, their traffic needed to be backhauled from the PE all the way to the centralized gateway where inter-subnet switching is performed and then sent back to the PE. For today's large multi-tenant Data Center (DC), this scheme is very inefficient and sometimes impractical.
サブネット間通信は通常、全てのサブネット間通信ポリシーを強制し、すべてのサブネット間転送を実行する集中型レイヤ3（L3）ゲートウェイ（GW）デバイスによって実行されます。同じプロバイダエッジ（PE）に接続されている2つの異なるサブネットに属する2つのTSが互いに通信したい場合、それらのトラフィックは、サブネット間の切り替えが実行されてから送信された中央値のゲートウェイまで、PEからPEからバックホールされる必要がありました。PEに戻る。今日の大規模マルチテナントデータセンター（DC）の場合、この方式は非常に非効率的であり、時には実用的ではありません。
In order to overcome the drawback of the centralized L3 GW approach, IRB functionality is needed on the PEs (also referred to as EVPN Network Virtualization Edges (NVEs)) attached to TSs in order to avoid inefficient forwarding of tenant traffic (i.e., avoid backhauling and hair pinning). When a PE with IRB capability receives tenant traffic over an Attachment Circuit (AC), it cannot only locally bridge the tenant intra-subnet traffic but also locally route the tenant inter-subnet traffic on a packet-by-packet basis, thus meeting the requirements for both intra- and inter-subnet forwarding and avoiding non-optimal traffic forwarding associated with a centralized L3 GW approach.
集中型L3 GWアプローチの欠点を克服するために、テナントトラフィックの非効率的な転送を回避するために、TSSに接続されたPES（EVPNネットワーク仮想化エッジ（NVES）とも呼ばれる）にIRB機能が必要とされる（すなわち、バックホールを回避するそして髪のピン止め）。IRB機能を備えたPEが添付回路（AC）を介してテナントトラフィックを受信すると、テナント内サブネットトラフィックをローカルにブリッジするだけでなく、テナント間サブネット間トラフィックをパケットごとにローカルでルーティングするだけで、サブネット間およびサブネット間転送の両方の要件集中L3 GWアプローチに関連した最適でないトラフィック転送を回避する。
Some TSs run non-IP protocols in conjunction with their IP traffic. Therefore, it is important to handle both kinds of traffic optimally -- e.g., to bridge non-IP and intra-subnet traffic and to route inter-subnet IP traffic. Therefore, the solution needs to meet the following requirements:
一部のTSSは、IPトラフィックと組み合わせて非IPプロトコルを実行します。したがって、非IPとサブネット内のトラフィックをブリッジし、サブネット間のIPトラフィックをルーティングするための両方の種類のトラフィックを最適に処理することが重要です。したがって、解決策は次の要件を満たす必要があります。
R1: The solution must provide each tenant with IP routing of its inter-subnet traffic and Ethernet bridging of its intra-subnet traffic and non-routable traffic, where non-routable traffic refers to both non-IP traffic and IP traffic whose version differs from the IP version configured in IP Virtual Routing and Forwarding (IP-VRF). For example, if an IP-VRF in an NVE is configured for IPv6 and that NVE receives IPv4 traffic on the corresponding VLAN, then the IPv4 traffic is treated as non-routable traffic.
R1：ソリューションは、サブネット間トラフィック間のIPルーティングと、サブネット内のトラフィックのイーサネットブリッジングと、ルーティング不可能なトラフィックのイーサネットブリッジングを提供する必要があります。ルーパネル非表示トラフィックは、バージョンの異なるIPトラフィックとIPトラフィックの両方を参照します。IPバーチャルルーティングと転送（IP-VRF）で設定されたIPバージョンから。たとえば、NVE内のIP-VRFがIPv6用に構成され、NVEが対応するVLANでIPv4トラフィックを受信した場合、IPv4トラフィックはルーティング不可能なトラフィックとして扱われます。
R2: The solution must allow IP routing of inter-subnet traffic to be disabled on a per-VLAN basis on those PEs that are backhauling that traffic to another PE for routing.
R2：ソリューションは、ルーティング用の別のPEへのトラフィックをバックホールなPESで、サブネット間トラフィックのIPルーティングをVLANごとに無効にする必要があります。
AC: Attachment Circuit
AC：取り付け回路
ARP: Address Resolution Protocol
ARP：アドレス解決プロトコル
ARP Table: A logical view of a forwarding table on a PE that maintains an IP to a MAC binding entry on an IP interface for both IPv4 and IPv6. These entries are learned through ARP/ND or through EVPN.
ARPテーブル：IPv4とIPv6の両方のIPインターフェイス上のIPをMACバインディングエントリに保持するPE上の転送テーブルの論理ビュー。これらのエントリは、ARP / NDまたはEVPNを介して学習されます。
BD: Broadcast Domain. As per [RFC7432], an EVI consists of a single BD or multiple BDs. In the case of VLAN-bundle and VLAN-based service models (see [RFC7432]), a BD is equivalent to an EVI. In the case of a VLAN-aware bundle service model, an EVI contains multiple BDs. Also, in this document, "BD" and "subnet" are equivalent terms, and wherever "subnet" is used, it means "IP subnet".
BD：ブロードキャストドメイン。[RFC7432]によると、EVIは単一のBDまたは複数のBDSで構成されています。VLAN-BUNDLEおよびVLANベースのサービスモデル（[RFC7432]参照）の場合、BDはEVIに相当します。VLAN対応バンドルサービスモデルの場合、EVIには複数のBDが含まれています。また、この文書では、「BD」と「サブネット」が同等の用語であり、「サブネット」が使用されているところは、「IPサブネット」を意味する。
BD Route Target: Refers to the broadcast-domain-assigned Route Target [RFC4364]. In the case of a VLAN-aware bundle service model, all the BD instances in the MAC-VRF share the same Route Target.
BDルートターゲット：ブロードキャストドメイン割り当てルートターゲット[RFC4364]を参照します。VLAN対応バンドルサービスモデルの場合、MAC-VRF内のすべてのBDインスタンスは同じルートターゲットを共有します。
BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per [RFC7432].
BT：ブリッジテーブル。[RFC7432]のように、MAC-VRF内のBDのインスタンス化。
CE: Customer Edge
CE：カスタマーエッジ
DA: Destination Address
DA：宛先アドレス
Ethernet NVO Tunnel: Refers to Network Virtualization Overlay tunnels with an Ethernet payload, as specified for VXLAN in [RFC7348] and for NVGRE in [RFC7637].
イーサネットNVOトンネル：[RFC7348]のVXLANおよび[RFC7637]のNVGREの場合は、イーサネットペイロードを持つネットワーク仮想化オーバーレイトンネルを参照してください。
EVI: EVPN Instance spanning NVE/PE devices that are participating on that EVPN, as per [RFC7432].
EVI：RFC7432のように、そのEVPNに参加しているNVE / PEデバイスにまたがるEVPNインスタンス。
EVPN: Ethernet VPN, as per [RFC7432].
EVPN：rfc7432のように、イーサネットVPN。
IP NVO Tunnel: Refers to Network Virtualization Overlay tunnels with IP payload (no MAC header in the payload) as specified for Generic Protocol Extension (GPE) in [VXLAN-GPE].
IP NVOトンネル：[VXLAN-GPE]のGeneric Protocol Extension（GPE）に指定されているIPペイロード（ペイロード内のMACヘッダーなし）のネットワーク仮想化オーバーレイトンネルを参照します。
IP-VRF: A Virtual Routing and Forwarding table for IP routes on an NVE/PE. The IP routes could be populated by EVPN and IP-VPN address families. An IP-VRF is also an instantiation of a Layer 3 VPN in an NVE/PE.
IP-VRF：NVE / PE上のIPルート用の仮想ルーティングおよび転送テーブル。IPルートはEVPNおよびIP-VPNアドレスファミリによって入力できます。IP-VRFは、NVE / PEにおけるレイヤ3 VPNのインスタンス化でもある。
IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a BD (or subnet).
IRB：統合ルーティングとブリッジングインタフェース。IP-VRFをBD（またはサブネット）に接続します。
MAC: Media Access Control
Mac：メディアアクセス制御
MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is also an instantiation of an EVI in an NVE/PE.
MAC-VRF：[RFC7432]のように、NVE / PE上のMACアドレスの仮想ルーティングおよび転送テーブル。MAC - VRFも、NVE / PEにおけるEVIのインスタンス化でもあります。
ND: Neighbor Discovery
ND：ネイバーディスカバリー
NVE: Network Virtualization Edge
NVE：ネットワーク仮想化エッジ
NVGRE: Network Virtualization Using Generic Routing Encapsulation, as per [RFC7637].
NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化（RFC7637]。
NVO: Network Virtualization Overlay
NVO：ネットワーク仮想化オーバーレイ
PE: Provider Edge
PE：プロバイダのエッジ
RT-2: EVPN Route Type 2, i.e., MAC/IP Advertisement route, as defined in [RFC7432].
RT-2：EVPNルートタイプ2、すなわち[RFC7432]で定義されているように、MAC / IPアドバタイズメントルート。
RT-5: EVPN Route Type 5, i.e., IP Prefix route, as defined in Section 3 of [RFC9136].
RT-5：[RFC9136]のセクション3で定義されているように、EVPNルートタイプ5、すなわちIPプレフィックスルート。
SA: Source Address
SA：送信元アドレス
TS: Tenant System
TS：テナントシステム
VA: Virtual Appliance
VA：仮想アプライアンス
VNI: Virtual Network Identifier. As in [RFC8365], the term is used as a representation of a 24-bit NVO instance identifier, with the understanding that "VNI" will refer to a VXLAN Network Identifier in VXLAN, or a Virtual Subnet Identifier in NVGRE, etc., unless it is stated otherwise.
VNI：仮想ネットワーク識別子。[RFC8365]と同様に、この用語は24ビットNVOインスタンス識別子の表現として使用され、「VNI」はVXLANのVXLANネットワーク識別子、またはNVGREなどの仮想サブネット識別子を参照することを理解しています。そうでなければ述べられない限り。
VTEP: VXLAN Termination End Point, as per [RFC7348].
VTEP：[RFC7348]のように、VXLAN終端終了点。
VXLAN: Virtual eXtensible Local Area Network, as per [RFC7348].
VXLAN：[RFC7348]のように、Virtual Extensible Local Area Network。
This document also assumes familiarity with the terminology of [RFC7365], [RFC7432], and [RFC8365].
この文書は、[RFC7365]、[RFC7432]、[RFC8365]の用語に精通していると仮定しています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Since this document discusses IRB operation in relationship to EVPN MAC-VRF, IP-VRF, EVI, BD, bridge table, and IRB interfaces, it is important to understand the relationship between these components. Therefore, the PE model is illustrated below to a) describe these components and b) illustrate the relationship among them.
この文書では、EVPN MAC-VRF、IP-VRF、EVI、BD、ブリッジテーブル、およびIRBインターフェイスとの関係のIRB動作について説明しているため、これらのコンポーネント間の関係を理解することが重要です。したがって、PEモデルを以下に示しており、これらの構成要素とB）はそれらの関係を説明する。
+-------------------------------------------------------------+
| |
| +------------------+ IRB PE |
| Attachment | +------------------+ |
| Circuit(AC1) | | +----------+ | MPLS/NVO tnl
----------------------*Bridge | | +-----
| | | |Table(BT1)| | +-----------+ / \ \
| | | | *---------* |<--> |Eth|
| | | | VLAN x | |IRB1| | \ / /
| | | +----------+ | | | +-----
| | | ... | | IP-VRF1 | |
| | | +----------+ | | RD2/RT2 |MPLS/NVO tnl
| | | |Bridge | | | | +-----
| | | |Table(BT2)| |IRB2| | / \ \
| | | | *---------* |<--> |IP |
----------------------* VLAN y | | +-----------+ \ / /
| AC2 | | +----------+ | +-----
| | | MAC-VRF1 | |
| +-+ RD1/RT1 | |
| +------------------+ |
| |
| |
+-------------------------------------------------------------+
Figure 1: EVPN IRB PE Model
図1：EVPN IRB PEモデル
A tenant needing IRB services on a PE requires an IP-VRF table along with one or more MAC-VRF tables. An IP-VRF, as defined in [RFC4364], is the instantiation of an IP-VPN instance in a PE. A MAC-VRF, as defined in [RFC7432], is the instantiation of an EVI in a PE. A MAC-VRF consists of one or more bridge tables, where each bridge table corresponds to a VLAN (broadcast domain). If service interfaces for an EVPN PE are configured in VLAN-based mode (i.e., Section 6.1 of [RFC7432]), then there is only a single bridge table per MAC-VRF (per EVI) -- i.e., there is only one tenant VLAN per EVI. However, if service interfaces for an EVPN PE are configured in VLAN-aware bundle mode (i.e., Section 6.3 of [RFC7432]), then there are several bridge tables per MAC-VRF (per EVI) -- i.e., there are several tenant VLANs per EVI.
PE上にIRBサービスを必要とするテナントには、1つ以上のMAC-VRFテーブルとともにIP-VRFテーブルが必要です。[RFC4364]で定義されているIP-VRFは、PE内のIP-VPNインスタンスのインスタンス化です。[RFC7432]で定義されているMAC-VRFは、PE内のEVIのインスタンス化です。MAC-VRFは1つ以上のブリッジテーブルで構成されており、各ブリッジテーブルはVLAN（ブロードキャストドメイン）に対応します。EVPN PEのサービスインタフェースがVLANベースのモードで設定されている場合（すなわち、[RFC7432]のセクション6.1）、MAC-VRFごとに単一のブリッジテーブル（EVIごと）があります - つまり、テナントが1つだけありますEVIあたりのVLAN。ただし、EVPN PEのサービスインタフェースがVLAN対応バンドルモード（すなわち[RFC7432]のセクション6.3）で構成されている場合は、MAC-VRFごとにいくつかのブリッジテーブルがあります（EVIごと） - すなわちいくつかのテナントがありますEVIあたりのVLAN。
Each bridge table is connected to an IP-VRF via an L3 interface called an "IRB interface". Since a single tenant subnet is typically (and in this document) represented by a VLAN (and thus supported by a single bridge table), for a given tenant, there are as many bridge tables as there are subnets. Thus, there are also as many IRB interfaces between the tenant IP-VRF and the associated bridge tables as shown in the PE model above.
各ブリッジテーブルは、「IRBインタフェース」というL3インターフェイスを介してIP-VRFに接続されています。単一のテナントサブネットは通常（そしてこの文書ではこのドキュメントで）、特定のテナントのために、サブネットがあるのと同じくらい多くのブリッジテーブルがあるので、（そしてこの文書では単一のブリッジテーブルによってサポートされています）。したがって、上記のPEモデルに示すように、テナントIP-VRFと関連するブリッジテーブルとの間にも多くのIRBインタフェースがある。
IP-VRF is identified by its corresponding Route Target and Route Distinguisher, and MAC-VRF is also identified by its corresponding Route Target and Route Distinguisher. If operating in EVPN VLAN-based mode, then a receiving PE that receives an EVPN route with a MAC-VRF Route Target can identify the corresponding bridge table; however, if operating in EVPN VLAN-aware bundle mode, then the receiving PE needs both the MAC-VRF Route Target and VLAN ID in order to identify the corresponding bridge table.
IP-VRFは対応するルートターゲットとルート識別器によって識別され、MAC-VRFはその対応するルートターゲットとルート識別器によっても識別されます。EVPN VLANベースモードで動作する場合は、MAC-VRFルートターゲットを持つEVPNルートを受信する受信PEは、対応するブリッジテーブルを識別できます。ただし、EVPN VLAN対応バンドルモードで動作している場合、受信PEは対応するブリッジテーブルを識別するためにMAC-VRFルートターゲットとVLAN IDの両方を必要とします。
This document defines and describes two types of IRB solutions -- namely, symmetric and asymmetric IRB. The description of symmetric and asymmetric IRB procedures relating to data path operations and tables in this document is a logical view of data path lookups and related tables. Actual implementations, while following this logical view, may not strictly adhere to it for performance trade-offs. Specifically,
この文書は2種類のIRBソリューションを定義し、対称および非対称IRBを定義して説明します。データパスの操作とテーブルに関する対称および非対称IRBプロシージャの説明は、データパスのルックアップおよび関連テーブルの論理ビューです。実際の実装は、この論理ビューの後に、パフォーマンストレードオフのためにそれを厳密に付着させることはできません。具体的には、
* References to an ARP table in the context of asymmetric IRB is a logical view of a forwarding table that maintains an IP-to-MAC binding entry on a Layer 3 interface for both IPv4 and IPv6. These entries are not subject to ARP or ND protocols. For IP-to-MAC bindings learned via EVPN, an implementation may choose to import these bindings directly to the respective forwarding table (such as an adjacency/next-hop table) as opposed to importing them to ARP or ND protocol tables.
* 非対称IRBのコンテキストにおけるARPテーブルへの参照は、IPv4とIPv6の両方のレイヤ3インターフェイス上のIPからMACバインディングエントリを維持する転送テーブルの論理ビューです。これらのエントリはARPまたはNDプロトコルの対象とはなりません。EVPN経由で学習されたIPからMACのバインディングの場合、それらをARPまたはNDプロトコルテーブルにインポートするのは対照的に、これらのバインディングをそれぞれの転送テーブル（隣接/ネクストホップテーブルなど）に直接インポートすることを選択できます。
* References to a host IP lookup followed by a host MAC lookup in the context of asymmetric IRB MAY be collapsed into a single IP lookup in a hardware implementation.
* 非対称IRBのコンテキストにおけるホストIPルックアップとそれに続くホストMACルックアップへの参照は、ハードウェア実装で単一のIP検索に折りたたまれてもよい。
In symmetric IRB, as its name implies, the lookup operation is symmetric at both the ingress and egress PEs -- i.e., both ingress and egress PEs perform lookups on both MAC and IP addresses. The ingress PE performs a MAC lookup followed by an IP lookup, and the egress PE performs an IP lookup followed by a MAC lookup, as depicted in the following figure.
対称IRBでは、その名前が暗示しているので、ルックアップ操作は入力と出力PESの両方で対称的であり、入力と出力PESの両方がMACアドレスとIPアドレスの両方で検索を実行します。入力PEは、MACルックアップとそれに続くIPルックアップを実行し、次の図に示すように、出力PEはIPルックアップとそれに続くMacルックアップを実行します。
Ingress PE Egress PE
+-------------------+ +------------------+
| | | |
| +-> IP-VRF ----|---->---|-----> IP-VRF -+ |
| | | | | |
| BT1 BT2 | | BT3 BT2 |
| | | | | |
| ^ | | v |
| | | | | |
+-------------------+ +------------------+
^ |
| |
TS1->-+ +->-TS2
Figure 2: Symmetric IRB
図2：対称IRB.
In symmetric IRB, as shown in Figure 2, the inter-subnet forwarding between two PEs is done between their associated IP-VRFs. Therefore, the tunnel connecting these IP-VRFs can be either an IP-only tunnel (e.g., in the case of MPLS or GPE encapsulation) or an Ethernet NVO tunnel (e.g., in the case of VXLAN encapsulation). If it is an Ethernet NVO tunnel, the TS1's IP packet is encapsulated in an Ethernet header consisting of ingress and egress PE MAC addresses -- i.e., there is no need for the ingress PE to use the destination TS2's MAC address. Therefore, in symmetric IRB, there is no need for the ingress PE to maintain ARP entries for the association of the destination TS2's IP and MAC addresses in its ARP table. Each PE participating in symmetric IRB only maintains ARP entries for locally connected hosts and MAC-VRFs/BTs for only locally configured subnets.
図2に示すように、対称IRBでは、2つのPE間の間のサブネット間転送は、関連するIP-VRFの間で行われます。したがって、これらのIP - VRFを接続するトンネルは、IP専用トンネル（例えば、MPLSまたはGPEカプセル化の場合）、またはイーサネットNVOトンネル（例えば、VxLANカプセル化の場合）のいずれかであり得る。イーサネットNVOトンネルであれば、TS1のIPパケットは、入力および出力PE MACアドレスからなるイーサネットヘッダにカプセル化されている - すなわち、宛先TS2のMACアドレスを使用するために入力PEが使用する必要はない。したがって、対称IRBでは、Ingress PEがそのARPテーブル内の宛先TS2のIPとMACアドレスの関連付けのARPエントリを維持する必要はありません。対称IRBに参加している各PEは、ローカルに設定されたサブネットのみにローカルに接続されたホストとMAC-VRFS / BTSのARPエントリを管理します。
In asymmetric IRB, the lookup operation is asymmetric and the ingress PE performs three lookups, whereas the egress PE performs a single lookup -- i.e., the ingress PE performs a MAC lookup, followed by an IP lookup, followed by a MAC lookup again. The egress PE performs just a single MAC lookup as depicted in Figure 3 below.
非対称IRBでは、ルックアップ操作は非対称であり、入力PEは3つの検索を実行し、出力PEは単一の検索を実行し、入力PEはMACルックアップを実行し、その後にIPルックアップを実行し、その後にIPルックアップを実行します。発注PEは、下の図3に示すように単一のMACルックアップだけを実行します。
Ingress PE Egress PE
+-------------------+ +------------------+
| | | |
| +-> IP-VRF -> | | IP-VRF |
| | | | | |
| BT1 BT2 | | BT3 BT2 |
| | | | | | | |
| | +--|--->----|--------------+ | |
| | | | v |
+-------------------+ +----------------|-+
^ |
| |
TS1->-+ +->-TS2
Figure 3: Asymmetric IRB
図3：非対称IRB.
In asymmetric IRB, as shown in Figure 3, the inter-subnet forwarding between two PEs is done between their associated MAC-VRFs/BTs. Therefore, the MPLS or NVO tunnel used for inter-subnet forwarding MUST be of type Ethernet. Since only MAC lookup is performed at the egress PE (e.g., no IP lookup), the TS1's IP packets need to be encapsulated with the destination TS2's MAC address. In order for the ingress PE to perform such encapsulation, it needs to maintain TS2's IP and MAC address association in its ARP table. Furthermore, it needs to maintain destination TS2's MAC address in the corresponding bridge table even though it may not have any TSs of the corresponding subnet locally attached. In other words, each PE participating in asymmetric IRB MUST maintain ARP entries for remote hosts (hosts connected to other PEs) as well as maintain MAC-VRFs/BTs and IRB interfaces for ALL subnets in an IP-VRF, including subnets that may not be locally attached. Therefore, careful consideration of the PE scale aspects for its ARP table size, its IRB interfaces, and the number and size of its bridge tables should be given for the application of asymmetric IRB.
非対称IRBでは、図3に示すように、2つのPE間のサブネット間転送は、関連するMAC-VRFS / BTSの間で行われます。したがって、サブネット間転送に使用されるMPLSまたはNVOトンネルは、イーサネット型のタイプでなければなりません。 MACルックアップのみが出力PE（例えば、IPルックアップなし）で実行されるので、TS1のIPパケットは宛先TS2のMACアドレスでカプセル化する必要があります。入力PEがそのようなカプセル化を実行するためには、ARPテーブルにTS2のIPおよびMACアドレスの関連付けを維持する必要があります。さらに、対応するサブネットのTSがローカルに接続されていなくても、宛先TS2のMACアドレスを対応するブリッジテーブルに維持する必要があります。言い換えれば、非対称IRBに参加している各PEは、リモートホスト（他のPESに接続されているホスト）のARPエントリを維持し、IP-VRF内のすべてのサブネットのMAC-VRFS / BTSおよびIRBインターフェイスを管理する必要があります。ローカルに取り付けてください。そのため、ARPテーブルサイズ、IRBインターフェイス、およびそのブリッジテーブルの数とサイズについては、非対称IRBのアプリケーションを慎重に検討してください。
It should be noted that whenever a PE performs a host IP lookup for a packet that is routed, the IPv4 Time To Live (TTL) or IPv6 hop limit for that packet is decremented by one, and if it reaches zero, the packet is discarded. In the case of symmetric IRB, the TTL / hop limit is decremented by both ingress and egress PEs (once by each), whereas in the case of asymmetric IRB, the TTL / hop limit is decremented only once by the ingress PE.
PEがルーティングされたパケットのホストIPルックアップを実行するたびに、そのパケットのIPv4時間（TTL）またはIPv6ホップ制限が1つずれ、ゼロに達すると破棄されます。。対称IRBの場合、TTL / HPの制限は入力PEと出力PESの両方によって（各々）によって減分されますが、非対称IRBの場合、TTL / HHPの制限は入力PEによって一度だけ減分されます。
The following sections define the control and data plane procedures for symmetric and asymmetric IRB on ingress and egress PEs. The following figure is used to describe these procedures, showing a single IP-VRF and a number of BDs on each PE for a given tenant. That is, an IP-VRF connects one or more EVIs, and each EVI contains one MAC-VRF; each MAC VRF consists of one or more bridge tables, one per BD; and a PE has an associated IRB interface for each BD.
以下のセクションでは、入力と出力PESの対称および非対称IRBの制御とデータプレーンの手順を定義します。次の図は、これらの手順を説明するために使用され、特定のテナントの各PE上の単一のIP-VRFおよび数のBDSを示します。つまり、IP-VRFは1つ以上のEVIを接続し、各EVIにはMAC-VRFが1つ含まれています。各MAC VRFは、1つ以上のブリッジテーブルで構成されています。PEは各BDに対して関連するIRBインタフェースを有する。
PE 1 +---------+
+-------------+ | |
TS1-----| MACx| | | PE2
(M1/IP1) |(BT1) | | | +-------------+
TS5-----| \ | | MPLS/ | |MACy (BT3) |-----TS3
(M5/IP5) |IPx/Mx \ | | VXLAN/ | | / | (M3/IP3)
| (IP-VRF1)|----| NVGRE |---|(IP-VRF1) |
| / | | | | \ |
TS2-----|(BT2) / | | | | (BT1) |-----TS4
(M2/IP2) | | | | | | (M4/IP4)
+-------------+ | | +-------------+
| |
+---------+
Figure 4: IRB Forwarding
図4：IRB転送
To support inter-subnet forwarding on a PE, the PE acts as an IP default gateway from the perspective of the attached Tenant Systems where default gateway MAC and IP addresses are configured on each IRB interface associated with its subnet and fall into one of the following two options:
PE上でのサブネット間転送をサポートするために、PEは、既定のテナントシステムの観点からIPデフォルトゲートウェイとして機能し、デフォルトゲートウェイMACおよびIPアドレスはそのサブネットに関連付けられた各IRBインタフェースに設定され、次のいずれかに分類されます。2つの選択肢：
1. All the PEs for a given tenant subnet use the same anycast default gateway IP and MAC addresses. On each PE, these default gateway IP and MAC addresses correspond to the IRB interface connecting the bridge table associated with the tenant's VLAN to the corresponding tenant's IP-VRF.
1. 特定のテナントサブネットのすべてのPEは、AnycastのデフォルトゲートウェイIPおよびMACアドレスを使用します。各PEでは、これらのデフォルトゲートウェイIPおよびMACアドレスは、テナントのVLANに関連付けられているブリッジテーブルを対応するテナントのIP-VRFに接続するIRBインタフェースに対応しています。
2. Each PE for a given tenant subnet uses the same anycast default gateway IP address but its own MAC address. These MAC addresses are aliased to the same anycast default gateway IP address through the use of the Default Gateway extended community as specified in [RFC7432], which is carried in the EVPN MAC/IP Advertisement routes. On each PE, this default gateway IP address, along with its associated MAC addresses, correspond to the IRB interface connecting the bridge table associated with the tenant's VLAN to the corresponding tenant's IP-VRF.
2. 特定のテナントサブネットの各PEは、anycastのデフォルトゲートウェイIPアドレスが同じではなく、独自のMACアドレスを使用します。これらのMACアドレスは、EVPN MAC / IPアドバタイズメントルートで搭載されている[RFC7432]で指定されたデフォルトゲートウェイ拡張コミュニティを使用して、同じAnycastのデフォルトゲートウェイIPアドレスにエイリアスされています。各PEでは、このデフォルトゲートウェイIPアドレスは、その関連MACアドレスとともに、テナントのVLANに関連付けられているブリッジテーブルを対応するテナントのIP-VRFに接続するIRBインタフェースに対応します。
It is worth noting that if the applications that are running on the TSs are employing or relying on any form of MAC security, then the first option (i.e., using an anycast MAC address) should be used to ensure that the applications receive traffic from the same IRB interface MAC address to which they are sending. If the second option is used, then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) for that TS.
TSS上で実行されているアプリケーションがMACセキュリティのいずれかのMACセキュリティを採用または頼っている場合、最初のオプション（すなわち、Anycast MACアドレスを使用する）を使用して、アプリケーションがトラフィックを受信するように使用する必要があります。それらが送信しているのと同じIRBインタフェースMACアドレス。2番目のオプションが使用されている場合、IRBインターフェイスMACアドレスは、そのTSの最初のARP応答またはNDネイバーアドバタイズメント（NA）で使用されているものでなければなりません。
Although both of these options are applicable to both symmetric and asymmetric IRB, option 1 is recommended because of the ease of anycast MAC address provisioning on not only the IRB interface associated with a given subnet across all the PEs corresponding to that VLAN but also on all IRB interfaces associated with all the tenant's subnets across all the PEs corresponding to all the VLANs for that tenant. Furthermore, it simplifies the operation as there is no need for Default Gateway extended community advertisement and its associated MAC aliasing procedure. Yet another advantage is that following host mobility, the host does not need to refresh the default GW ARP/ND entry.
これらのオプションは両方のオプションと非対称IRBの両方に適用されますが、そのVLANに対応するすべてのPESに対応するすべてのPESに対応するすべてのPESに関連するIRBインタフェースではなく、Anycast MACアドレスのプロビジョニングがすべての場合、オプション1が推奨されます。そのテナントのすべてのVLANに対応するすべてのPESに対応するすべてのPESに対応するすべてのPESに対応するすべてのテナントのサブネットに関連付けられているIRBインタフェース。さらに、デフォルトのゲートウェイ拡張コミュニティアドバタイズメントとその関連MACエイリアシング手順が不要なため、動作を簡素化します。さらに別の利点は、ホストモビリティに続く、ホストはデフォルトのGW ARP / NDエントリを更新する必要はないことである。
If option 1 is used, an implementation MAY choose to auto-derive the anycast MAC address. If auto-derivation is used, the anycast MAC MUST be auto-derived out of the following ranges (which are defined in [RFC5798]):
オプション1が使用されている場合、実装はAnycast MACアドレスを自動導出することを選択できます。自動派生が使用されている場合、Anycast Macは次の範囲（[RFC5798]で定義されている）から自動的に導出されている必要があります。
* Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID}
* Anycast IPv4 IRBケース：00-00-5E-00-01- {vrid}
* Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID}
* Anycast IPv6 IRBケース：00-00-5E-00-02- {vrid}
Where the last octet is generated based on a configurable Virtual Router ID (VRID) (range 1-255). If not explicitly configured, the default value for the VRID octet is '1'. Auto-derivation of the anycast MAC can only be used if there is certainty that the auto-derived MAC does not collide with any customer MAC address.
最後のオクテットは、設定可能な仮想ルータID（VRID）に基づいて生成されます（1~255の範囲）。明示的に設定されていない場合、VRIDオクテットのデフォルト値は '1'です。Aunercast Macの自動派生は、自動派生MACが顧客MACアドレスと衝突しない確実性がある場合にのみ使用できます。
In addition to IP anycast addresses, IRB interfaces can be configured with non-anycast IP addresses for the purpose of OAM (such as sending a traceroute/ping to these interfaces) for both symmetric and asymmetric IRB. These IP addresses need to be distributed as VPN routes when PEs operate in symmetric IRB mode. However, they don't need to be distributed if the PEs are operating in asymmetric IRB mode as the non-anycast IP addresses are configured along with their individual MACs, and they get distributed via the EVPN route type 2 advertisement.
IP Anycastアドレスに加えて、IRBインタフェースは、OAM（これらのインタフェースへのTraceroute / Pingをこれらのインタフェースに送信するなど）では、対称IRBと非対称IRBの両方のIRBインターフェイスで設定できます。PESが対称IRBモードで動作すると、これらのIPアドレスをVPNルートとして配布する必要があります。ただし、PESが非対称IRBモードで動作している場合は、個々のMACSと一緒に構成されている場合は、PESが非対称IRBモードで動作している場合は配布する必要はありません。これは、EVPNルートタイプ2アドバタイズメントを介して配布されます。
For option 1 -- irrespective of whether only the anycast MAC address or both anycast and non-anycast MAC addresses (where the latter one is used for the purpose of OAM) are used on the same IRB -- when a TS sends an ARP request or ND Neighbor Solicitation (NS) to the PE to which it is attached, the request is sent for the anycast IP address of the IRB interface associated with the TS's subnet. The reply will use an anycast MAC address (in both the source MAC in the Ethernet header and sender hardware address in the payload). For example, in Figure 4, TS1 is configured with the anycast IPx address as its default gateway IP address; thus, when it sends an ARP request for IPx (anycast IP address of the IRB interface for BT1), the PE1 sends an ARP reply with the MACx, which is the anycast MAC address of that IRB interface. Traffic routed from IP-VRF1 to TS1 uses the anycast MAC address as the source MAC address.
オプション1の場合 - Anycast MACアドレスまたはエニーキャストMACアドレスと非Anrast MACアドレスのみ（後者がOAMの目的に使用されている場合）のみに関係なく、同じIRBで使用されます.TSがARP要求を送信するときまたは接続されているPEへのNDネイバー勧誘（NS）は、TSのサブネットに関連付けられているIRBインターフェイスのAnycast IPアドレスについて要求が送信されます。返信は、（イーサネットヘッダーのソースMacとペイロードの送信者のハードウェアアドレスの両方で）Anycast MACアドレスを使用します。たとえば、図4では、TS1はAnycast IPXアドレスをデフォルトのゲートウェイIPアドレスで構成されています。したがって、IPXのARP要求（BT1のIRBインタフェースのAnycast IPアドレス）を送信すると、PE1はARP応答をMACXで送信します。これは、そのIRBインターフェイスのAnycast MACアドレスです。IP-VRF1からTS1にルーティングされたトラフィックは、Anycast MACアドレスを送信元MACアドレスとして使用します。
Symmetric and asymmetric IRB modes may coexist in the same network, and an ingress PE that supports both forwarding modes for a given tenant can interwork with egress PEs that support either IRB mode. The egress PE will indicate the desired forwarding mode for a given host based on the presence of the Label2 field and the IP-VRF Route Target in the EVPN MAC/IP Advertisement route. If the Label2 field of the received MAC/IP Advertisement route for host H1 is non-zero, and one of its Route Targets identifies the IP-VRF, the ingress PE will use symmetric IRB mode when forwarding packets destined to H1. If the Label2 field is zero and the MAC/IP Advertisement route for H1 does not carry any Route Target that identifies the IP-VRF, the ingress PE will use asymmetric mode when forwarding traffic to H1.
対称的および非対称IRBモードは、同じネットワーク内で共存することができ、特定のテナントの両方の転送モードをサポートする入力PEは、IRBモードのいずれかをサポートする出力PEと相互作用できます。出力PEは、EVPN MAC / IPアドバタイズメントルート内のLabel2フィールドとIP-VRFルートターゲットの存在に基づいて、特定のホストの希望の転送モードを示します。ホストH1用の受信MAC / IPアドバタイズメントルートのLABEL2フィールドがゼロ以外で、そのルートターゲットの1つがIP-VRFを識別している場合、入力PEはH1宛のパケットを転送するときに対称IRBモードを使用します。LABEL2フィールドがゼロで、H1のMAC / IPアドバタイズメントルートがIP-VRFを識別するルートターゲットを担当しない場合、Ingress PEはトラフィックをH1に転送するときに非対称モードを使用します。
As an example that illustrates the previous statement, suppose PE1 and PE2 need to forward packets from TS2 to TS4 in Figure 4. Since both PEs are attached to the bridge table of the destination host, symmetric and asymmetric IRB modes are both possible as long as the ingress PE, PE1, supports both modes. The forwarding mode will depend on the mode configured in the egress PE, PE2. That is:
以前のステートメントを示す例として、PE1とPE2は図4のTS2からTS4のパケットを転送する必要があるとします。両方のPESは宛先ホストのブリッジテーブルに接続されているため、対称と非対称IRBモードはどちらも可能です。入力PE、PE1は両方のモードをサポートします。転送モードは、出力PE、PE2に設定されたモードによって異なります。あれは：
1. If PE2 is configured for symmetric IRB mode, PE2 will advertise TS4 MAC/IP addresses in a MAC/IP Advertisement route with a non-zero Label2 field, e.g., Label2 = Lx, and a Route Target that identifies IP-VRF1 in PE1. IP4 will be installed in PE1's IP-VRF1; TS4's ARP and MAC information will also be installed in PE1's IRB interface ARP table and BT1, respectively. When a packet from TS2 destined to TS4 is looked up in PE1's IP-VRF route table, a longest prefix match lookup will find IP4 in the IP-VRF, and PE1 will forward using the symmetric IRB mode and Label Lx.
1. PE2が対称IRBモードに設定されている場合、PE2は、ゼロ以外のLabel2フィールド、例えばLabel2 = LX、およびPE1でIP-VRF1を識別するルートターゲットを使用してMAC / IPアドレスをアドレス指定します。IP4はPE1のIP-VRF1にインストールされます。TS4のARPおよびMAC情報は、それぞれPE1のIRBインタフェースARPテーブルおよびBT1にもインストールされます。TS2からTS4のパケットがPE1のIP-VRFルートテーブルで検索されると、最長のプレフィックス一致検索はIP-VRFでIP4を見つけ、PE1は対称IRBモードとラベルLXを使用してPE1は転送されます。
2. However, if PE2 is configured for asymmetric IRB mode, PE2 will advertise TS4 MAC/IP information in a MAC/IP Advertisement route with a zero Label2 field and no Route Target identifying IP-VRF1. In this case, PE2 will install TS4 information in its ARP table and BT1. When a packet from TS2 to TS4 arrives at PE1, a longest prefix match on IP-VRF1's route table will yield the local IRB interface to BT1, where a subsequent ARP and bridge table lookup will provide the information for an asymmetric forwarding mode to PE2.
2. ただし、PE2が非対称IRBモード用に構成されている場合、PE2はTS4 MAC / IP情報をMAC / IPアドバタイズメントルートにゼロのLABEL2フィールドとIP-VRF1を識別しているルートターゲットを指定しません。この場合、PE2はARPテーブルとBT1にTS4情報をインストールします。TS2からTS4へのパケットがPE1に到着すると、IP-VRF1のルートテーブルの最長プレフィックス一致がBT1へのローカルIRBインタフェースを生成します。ここで、後続のARPとブリッジテーブルルックアップは、非対称転送モードの情報をPE2に提供します。
Refer to [EVPN] for more information about interoperability between symmetric and asymmetric forwarding modes.
対称転送モードと非対称転送モード間の相互運用性の詳細については、[EVPN]を参照してください。
The choice between symmetric or asymmetric mode is based on the operator's preference, and it is a trade-off between scale (which is better in the symmetric IRB mode) and control plane simplicity (asymmetric IRB mode simplifies the control plane). In cases where a tenant has hosts for every subnet attached to all (or most of) the PEs, the ARP and MAC entries need to be learned by all PEs anyway; therefore, the asymmetric IRB mode simplifies the forwarding model and saves space in the IP-VRF route table, since host routes are not installed in the route table. However, if the tenant does not need to stretch subnets (broadcast domains) to multiple PEs and inter-subnet forwarding is needed, the symmetric IRB model will save ARP and bridge table space in all the PEs (in comparison with the asymmetric IRB model).
対称モードまたは非対称モードの選択は、オペレータの好みに基づいており、スケール間のトレードオフ（対称IRBモードではより良い）と制御面の単純さ（非対称IRBモードが制御面を単純化する）です。PESのすべて（またはほとんど）に接続されているすべてのサブネットに対してテナントがホストを持っている場合、ARPおよびMACエントリはとにかくすべてのPESによって学習する必要があります。したがって、ホストルートがルートテーブルにインストールされていないため、非対称IRBモードは転送モデルを簡素化し、IP-VRFルートテーブル内のスペースを保存します。ただし、テナントがサブネット（ブロードキャストドメイン）を複数のPESにストレッチする必要がない場合は、SOMMETRIC IRBモデルはすべてのPESでARPとブリッジ表スペースを保存します（非対称IRBモデルと比較して）。。
When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address of a TS (e.g., via an ARP request or Neighbor Solicitation), it adds the MAC address to the corresponding MAC-VRF/BT of that tenant's subnet and adds the IP address to the IP-VRF for that tenant. Furthermore, it adds this TS's MAC and IP address association to its ARP table or Neighbor Discovery Protocol (NDP) cache. It then builds an EVPN MAC/IP Advertisement route (type 2) as follows and advertises it to other PEs participating in that tenant's VPN.
PE（上記の図4のPE1）がTSのMACおよびIPアドレス（例えば、ARP要求または隣接勧誘を介して）を学習するとき、それはそのテナントのサブネットの対応するMAC - VRF / BTにMACアドレスを追加する。そしてそのテナントのIPアドレスをIP-VRFに追加します。さらに、このTSのMACとIPアドレスの関連付けとIPアドレスの関連付けをARPテーブルまたはネイバーディスカバリプロトコル（NDP）キャッシュに追加します。次に、次のようにEVPN MAC / IPアドバタイズメントルート（タイプ2）を構築し、そのテナントのVPNに参加している他のPESにアドバタイズします。
* The Length field of the BGP EVPN Network Layer Reachability Information (NLRI) for an EVPN MAC/IP Advertisement route MUST be either 40 (if the IPv4 address is carried) or 52 (if the IPv6 address is carried).
* EVPN MAC / IPアドバタイズメントルートのBGP EVPNネットワーク層到達可能性情報（NLRI）の長さフィールドは、40（IPv4アドレスが搬送されている場合）または52（IPv6アドレスが運ばれる場合）のいずれかでなければなりません。
* The Route Distinguisher (RD), Ethernet Segment Identifier, Ethernet Tag ID, MAC Address Length, MAC Address, IP Address Length, IP Address, and MPLS Label1 fields MUST be set per [RFC7432] and [RFC8365].
* ルート識別子（RD）、イーサネットセグメント識別子、イーサネットタグID、MACアドレス長、MACアドレス、IPアドレス長、IPアドレス、およびMPLS LABEL1フィールドは、[RFC7432]と[RFC8365]で設定する必要があります。
* The MPLS Label2 field is set to either an MPLS label or a VNI corresponding to the tenant's IP-VRF. In the case of an MPLS label, this field is encoded as 3 octets, where the high-order 20 bits contain the label value.
* MPLS LABEL2フィールドは、テナントのIP-VRFに対応するMPLSラベルまたはVNIのいずれかに設定されています。MPLSラベルの場合、このフィールドは3オクテットとしてエンコードされ、高次20ビットはラベル値を含みます。
Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length, MAC Address, IP Address Length, and IP Address fields are part of the route key used by BGP to compare routes. The rest of the fields are not part of the route key.
[RFC7432]と同様に、RD、イーサネットタグID、MACアドレス長、MACアドレス、IPアドレス長、およびIPアドレスフィールドは、ルートを比較するためにBGPで使用されるルートキーの一部です。残りのフィールドはルートキーの一部ではありません。
This route is advertised along with the following two extended communities:
このルートは、次の2つの拡張コミュニティとともに宣伝されています。
1. Encapsulation Extended Community
1. カプセル化拡張コミュニティ
2. EVPN Router's MAC Extended Community
2. EVPNルーターのMac Extended Community.
This route is advertised with one or more Encapsulation Extended Communities [RFC9012], one for each encapsulation type supported by the advertising PE. If one or more encapsulation types require an Ethernet frame, a single EVPN Router's MAC Extended Community (Section 8.1) is also advertised. This extended community specifies the MAC address to be used as the inner destination MAC address in an Ethernet frame sent to the advertising PE.
このルートは、広告PEでサポートされている各カプセル化タイプに対して1つずつ、1つ以上のカプセル化拡張コミュニティ[RFC9012]でアドバタイズされます。1つ以上のカプセル化タイプがイーサネットフレームを必要とする場合、単一のEVPNルータのMAC拡張コミュニティ（セクション8.1）もアドバタイズされます。この拡張コミュニティは、広告PEに送信されたイーサネットフレーム内の内部宛先MACアドレスとして使用されるMACアドレスを指定します。
This route MUST be advertised with two Route Targets, one corresponding to the MAC-VRF of the tenant's subnet and another corresponding to the tenant's IP-VRF.
このルートは、テナントのサブネットのMAC-VRFに対応する2つのルートターゲットでアドバタイズしなければなりません。これは、テナントのサブネットのMAC-VRFとテナントのIP-VRFに対応しています。
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertisement route, it performs the following:
PE（上記の図4のPE2）がこのEVPN MAC / IPアドバタイズメントルートを受信すると、次のようになります。
* The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are used to identify the correct MAC-VRF and bridge table, and if they are found, the MAC address is imported. The IP-VRF Route Target is used to identify the correct IP-VRF, and if it is found, the IP address is imported.
* 後者がゼロ以外の場合、MAC-VRFルートターゲットおよびイーサネットタグは、正しいMAC-VRFおよびBRIDSテーブルを識別するために使用され、見つかった場合はMACアドレスがインポートされます。IP-VRFルートターゲットは正しいIP-VRFを識別するために使用され、見つかった場合はIPアドレスがインポートされます。
If the MPLS Label2 field is non-zero, it means that this route is to be used for symmetric IRB, and the MPLS label2 value is to be used when sending a packet for this IP address to the advertising PE.
MPLS LABEL2フィールドがゼロ以外の場合、このルートを対称IRBに使用することを意味し、このIPアドレスのパケットを広告PEに送信するときにMPLS Label2の値を使用します。
If the receiving PE supports asymmetric IRB mode and receives this route with both the MAC-VRF and IP-VRF Route Targets but the MAC/IP Advertisement route does not include the MPLS Label2 field, then the receiving PE installs the MAC address in the corresponding MAC-VRF and the (IP, MAC) association in the ARP table for that tenant (identified by the corresponding IP-VRF Route Target).
受信側PEが非対称IRBモードをサポートし、このルートをMAC-VRFとIP-VRFルートターゲットの両方で受信しますが、MAC / IPアドバタイズメントルートにMPLS LABEL2フィールドが含まれていない場合、受信側PEはMACアドレスを対応するMACアドレスをインストールします。そのテナントのARPテーブル内のMAC-VRFと（IP、MAC）の関連付け（対応するIP-VRFルートターゲットによって識別されます）。
If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route Targets, and if the receiving PE does not support either asymmetric or symmetric IRB modes but has the corresponding MAC-VRF, then it only imports the MAC address.
受信側PEがMAC-VRFとIP-VRFルートターゲットの両方でこのルートを受信した場合、受信側PEが非対称または対称IRBモードのいずれかをサポートしていないが、対応するMAC-VRFをサポートしている場合は、MACアドレスをインポートします。
If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST ignore the MPLS Label2 field and install the MAC address in the corresponding MAC-VRF and (IP, MAC) association in the ARP table for that tenant (identified by the corresponding IP-VRF Route Target).
受信側PEがMAC - VRFルートターゲットとIP-VRFルートターゲットの両方でこのルートを受信し、MAC / IPアドバタイズメントルートの両方にMPLS LABEL2フィールドが含まれていますが、受信PEは非対称IRBモードのみをサポートしているため、受信側PEはMPLS LABEL2を無視する必要があります。そのテナント（対応するIP-VRFルートターゲットによって識別される）のARPテーブル内の対応するMAC-VRFおよび（IP、MAC）のARPのフィールドとインストール。
In the case of symmetric IRB, a Layer 3 subnet and IRB interface corresponding to a MAC-VRF/BT are required to be provisioned at a PE only if that PE has locally attached hosts in that subnet. In order to enable inter-subnet routing across PEs in a deployment where not all subnets are provisioned at all PEs participating in an EVPN IRB instance, PEs MUST advertise local subnet routes as EVPN RT-5. These subnet routes are required for bootstrapping host (IP, MAC) learning using gleaning procedures initiated by an inter-subnet data packet.
対称IRBの場合、MAC - VRF / BTに対応するレイヤ3サブネットおよびIRBインタフェースは、そのPEがそのサブネット内のローカルに接続されたホストを有する場合にのみPEでプロビジョニングされる必要がある。すべてのサブネットがEVPN IRBインスタンスに参加しているすべてのPESでプロビジョニングされている展開でPESでサブネット間のルーティングを有効にするには、PESはEVPN RT-5としてローカルサブネットルートをアドバタイズする必要があります。これらのサブネット経路は、サブネット間データパケットによって開始された集光手順を使用して、ブートストラップホスト（IP、MAC）の学習に必要です。
That is, if a given host's (IP, MAC) association is unknown, and an ingress PE needs to send a packet to that host, then that ingress PE needs to know which egress PEs are attached to the subnet in which the host resides in order to send the packet to one of those PEs, causing the PE receiving the packet to probe for that host. For example, consider a subnet A that is locally attached to PE1 and subnet B that is locally attached to PE2 and PE3. Host A in subnet A, which is attached to PE1, initiates a data packet destined to host B in subnet B, which is attached to PE3. If host B's (IP, MAC) has not yet been learned via either a gratuitous ARP OR a prior gleaning procedure, a new gleaning procedure MUST be triggered for host B's (IP, MAC) to be learned and advertised across the EVPN network. Since host B's subnet is not local to PE1, an IP lookup for host B at PE1 will not trigger this gleaning procedure for host B's (IP, MAC). Therefore, PE1 MUST learn subnet B's prefix route via EVPN RT-5 advertised from PE2 and PE3, so it can route the packet to one of the PEs that have subnet B locally attached. Once the packet is received at PE2 OR PE3, and the route lookup yields a glean result, an ARP request is triggered and flooded across the Layer 2 overlay. This ARP request would be received and replied to by host B, resulting in host B (IP, MAC) learning at PE3 and its advertisement across the EVPN network. Packets from host A to host B can now be routed directly from PE1 to PE3. Advertisement of local subnet EVPN RT-5 for an IP-VRF MAY typically be achieved via provisioning-connected route redistribution to BGP.
入口PEは、PEのは、ホストが存在するサブネットに取り付けられた出口知る必要があること、次に、所定のホストの（IP、MAC）アソシエーションが未知である場合、であり、PEはそのホストにパケットを送信する必要がある入力そのそのホストを探索するためにパケットを受信PEを引き起こし、それらのPEのいずれかにパケットを送信します。例えば、局所的に、局所的PE2及びPE3に取り付けられ、PE1およびサブネットBに取り付けられたサブネットAを考えます。 PE1に取り付けられたサブネットA、開始するPE3に取り付けられたサブネットB内のホストB宛のデータパケットのホストA。ホストBの（IP、MAC）はまだ無償ARPまたは以前の落穂拾いの手順のいずれかを介して学習されていない場合は、新しいグリーニング手順が学んだとEVPNネットワーク上でアドバタイズされるホストBの（IP、MAC）のためにトリガされなければなりません。ホストBのサブネットがPE1にローカルではないので、PE1でホストBのIPルックアップがホストBの（IP、MAC）のために、この落穂拾い手順をトリガしません。したがって、PE1はEVPN RT-5を介してサブネットBのプレフィックスルートを学ばなければならない、それがローカルに接続されたサブネットBを持っているPEのいずれかにパケットをルーティングすることができますので、PE2とPE3から宣伝しました。パケットがPE2 OR PE3で受信され、ルートルックアップがグリーニング結果を生成すると、ARP要求がトリガされ、レイヤ2オーバーレイ全体にフラッディングされます。このARP要求を受信し、ホストB（IP、MAC）PE3での学習とEVPNネットワーク全体の広告で、その結果、ホストBによって回答されます。ホストAからホストBへのパケットは今PE3にPE1から直接転送することができます。ローカルサブネットEVPN RT-5 IP-VRF MAYのための広告は、通常、BGPにプロビジョニング、接続ルート再配布を介して実現します。
When an Ethernet frame is received by an ingress PE (e.g., PE1 in Figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify the associated MAC-VRF/BT, and it performs a lookup on the destination MAC address. If the MAC address corresponds to its IRB interface MAC address, the ingress PE deduces that the packet must be inter-subnet routed. Hence, the ingress PE performs an IP lookup in the associated IP-VRF table. The lookup identifies the BGP next hop of the egress PE along with the tunnel/encapsulation type and the associated MPLS/VNI values. The ingress PE also decrements the TTL / hop limit for that packet by one, and if it reaches zero, the ingress PE discards the packet.
イーサネットネットフレームが入力PEによって（例えば、上記の図4のPE1）によって受信されると、PEはAC ID（例えばVLAN ID）を使用して関連するMAC - VRF / BTを識別し、それは宛先の検索を実行する。Macアドレス。MACアドレスがIRBインタフェースMACアドレスに対応する場合、入力PEはパケットがサブネット間ルーティングされている必要があることを推測します。したがって、入力PEは、関連するIP-VRFテーブルにIPルックアップを実行します。ルックアップは、トンネル/カプセル化タイプと関連するMPLS / VNI値とともに、出力PEのBGPネクストホップを識別します。入力PEは、そのパケットのTTL / HPの制限も1つずつ減少し、ゼロに達すると、入力PEはパケットを破棄します。
If the tunnel type is that of an MPLS or IP-only NVO tunnel, then the TS's IP packet is sent over the tunnel without any Ethernet header. However, if the tunnel type is that of an Ethernet NVO tunnel, then an Ethernet header needs to be added to the TS's IP packet. The source MAC address of this inner Ethernet header is set to the ingress PE's router MAC address, and the destination MAC address of this inner Ethernet header is set to the egress PE's router MAC address learned via the EVPN Router's MAC Extended Community attached to the route. The MPLS VPN label is set to the received label2 in the route. In the case of the Ethernet NVO tunnel type, the VNI may be set one of two ways:
トンネルタイプがMPLSまたはIPのみのNVOトンネルのものである場合、TSのIPパケットはイーサネットヘッダーなしでトンネルを介して送信されます。ただし、トンネルタイプがイーサネットNVOトンネルのものである場合は、イーサネットヘッダーをTSのIPパケットに追加する必要があります。この内部イーサネットヘッダーの送信元MACアドレスは入力PEのルータMACアドレスに設定され、この内部イーサネットヘッダーの宛先MACアドレスは、ルートに接続されているEVPNルーターのMac Extended Communityを介して学んだEgress PEのルータMACアドレスに設定されます。。MPLS VPNラベルは、経路内の受信したLabel2に設定されています。イーサネットNVOトンネルタイプの場合、VNIは2つの方法のうちの1つに設定され得る。
downstream mode: The VNI is set to the received label2 in the route, which is downstream assigned.
ダウンストリームモード：VNIは経路内の受信LABEL2に設定されます。これは下流の割り当てです。
global mode: The VNI is set to the received label2 in the route, which is assigned domain-wide. This VNI value from the received label2 MUST be the same as the locally configured VNI for the IP-VRF as all PEs in the NVO MUST be configured with the same IP-VRF VNI for this mode of operation. If the received label2 value does not match the locally configured VNI value, the route MUST NOT be used, and an error message SHOULD be logged.
グローバルモード：VNIは、ドメイン全体に割り当てられているルートの受信Label2に設定されています。受信したLabel2からのこのVNI値は、NVO内のすべてのPEを同じIP-VRF VNIで構成する必要があるため、この動作モードでは同じIP-VRF VNIを設定する必要があるため、IP-VRFのローカルに設定されているVNIと同じでなければなりません。受信したLabel2の値がローカルに設定されたVNI値と一致しない場合は、経路を使用しないでください。エラーメッセージを記録する必要があります。
PEs may be configured to operate in one of these two modes depending on the administrative domain boundaries across PEs participating in the NVO and the PE's capability to support downstream VNI mode.
PESは、NVOに参加しているPESの両端の管理ドメイン境界に応じて、およびダウンストリームVNIモードをサポートするPEの機能に応じて、これら2つのモードのうちの1つで動作するように構成されてもよい。
In the case of NVO tunnel encapsulation, the outer source and destination IP addresses are set to the ingress and egress PE BGP next-hop IP addresses, respectively.
NVOトンネルカプセル化の場合、外部ソースおよび宛先IPアドレスはそれぞれ入力および出力PE BGPネクストホップIPアドレスに設定される。
When the tenant's MPLS or NVO encapsulated packet is received over an MPLS or NVO tunnel by the egress PE, the egress PE removes the NVO tunnel encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup needs to be performed. If the VPN MPLS label or VNI identifies a MAC-VRF instead of an IP-VRF, then the procedures in Section 6.4 for asymmetric IRB are executed.
テナントのMPLSまたはNVOカプセル化パケットがEGRESS PEによってMPLSまたはNVOトンネルを介して受信されると、EGRESS PEはNVOトンネルカプセル化を削除し、VPN MPLSラベル（MPLSカプセル化用）またはVNI（NVOカプセル化の場合）を使用してIP-VRFが実行される必要があるIP-VRF。VPN MPLS LABELまたはVNIがIP-VRFの代わりにMAC-VRFを識別した場合、非対称IRBの6.4項の手順が実行されます。
The lookup in the IP-VRF identifies a local adjacency to the IRB interface associated with the egress subnet's MAC-VRF/BT. The egress PE also decrements the TTL / hop limit for that packet by one, and if it reaches zero, the egress PE discards the packet.
IP-VRFの検索は、出力サブネットのMAC-VRF / BTに関連付けられているIRBインターフェイスへのローカル隣接関係を識別します。出口PEはまた、そのパケットのTTL / HOP制限を1つずつ減少させ、それがゼロに達すると、出力PEはパケットを破棄する。
The egress PE gets the destination TS's MAC address for that TS's IP address from its ARP table or NDP cache. It encapsulates the packet with that destination MAC address and a source MAC address corresponding to that IRB interface and sends the packet to its destination subnet MAC-VRF/BT.
EGRESS PEは、そのTSのIPアドレスの宛先TSのMACアドレスをARPテーブルまたはNDPキャッシュから取得します。それはその宛先MACアドレスとそのIRBインタフェースに対応する送信元MACアドレスとのパケットをカプセル化し、そのパケットをその宛先サブネットMAC - VRF / BTに送信する。
The destination MAC address lookup in the MAC-VRF/BT results in the local adjacency (e.g., local interface) over which the Ethernet frame is sent.
MAC - VRF / BT内の宛先MACアドレス検索は、イーサネットフレームが送信されるローカル隣接（例えばローカルインタフェース）になる。
When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address of an attached TS (e.g., via an ARP request or ND Neighbor Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP table or NDP cache just as in the case for symmetric IRB. It then builds an EVPN MAC/IP Advertisement route (type 2) as follows and advertises it to other PEs participating in that tenant's VPN.
PE（上記の図4のPE1）が接続されているTSのMACおよびIPアドレス（例えば、ARP要求またはNDネイバー勧誘を介して）を学習するとき、それはそのMAC - VRF / BT、IP - VRF、およびARPを入力する。対称IRBの場合と同様に、テーブルまたはNDPキャッシュ。次に、次のようにEVPN MAC / IPアドバタイズメントルート（タイプ2）を構築し、そのテナントのVPNに参加している他のPESにアドバタイズします。
* The Length field of the BGP EVPN NLRI for an EVPN MAC/IP Advertisement route MUST be either 37 (if an IPv4 address is carried) or 49 (if an IPv6 address is carried).
* EVPN MAC / IPアドバタイズメントルートのBGP EVPN NLRの長さフィールドは、37（IPv4アドレスが搬送されている場合）または49（IPv6アドレスが運ばれている場合）のいずれかでなければなりません。
* The RD, Ethernet Segment Identifier, Ethernet Tag ID, MAC Address Length, MAC Address, IP Address Length, IP Address, and MPLS Label1 fields MUST be set per [RFC7432] and [RFC8365].
* RD、イーサネットセグメント識別子、イーサネットタグID、イーサネットタグID、MACアドレス長、MACアドレス、IPアドレス長、IPアドレス、およびMPLS Label1フィールドは、[RFC7432]と[RFC8365]に設定する必要があります。
* The MPLS Label2 field MUST NOT be included in this route.
* MPLS Label2フィールドはこのルートに含めてはいけません。
Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length, MAC Address, IP Address Length, and IP Address fields are part of the route key used by BGP to compare routes. The rest of the fields are not part of the route key.
[RFC7432]と同様に、RD、イーサネットタグID、MACアドレス長、MACアドレス、IPアドレス長、およびIPアドレスフィールドは、ルートを比較するためにBGPで使用されるルートキーの一部です。残りのフィールドはルートキーの一部ではありません。
This route is advertised along with the following extended community:
このルートは、次の拡張コミュニティとともに宣伝されています。
* Tunnel Type Extended Community
* トンネルタイプ拡張コミュニティ
For asymmetric IRB mode, the EVPN Router's MAC Extended Community is not needed because forwarding is performed using destination TS's MAC address, which is carried in this EVPN route type 2 advertisement.
非対称IRBモードでは、このEVPNルートタイプ2の広告で搭載されている宛先TSのMACアドレスを使用して転送が実行されるため、EVPNルータのMAC拡張コミュニティは必要ありません。
This route MUST always be advertised with the MAC-VRF Route Target. It MAY also be advertised with a second Route Target corresponding to the IP-VRF.
このルートは常にMAC-VRFルートターゲットでアドバタイズする必要があります。IP - VRFに対応する第2の経路ターゲットでアドバタイズされてもよい。
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertisement route, it performs the following:
PE（上記の図4のPE2）がこのEVPN MAC / IPアドバタイズメントルートを受信すると、次のようになります。
* Using the MAC-VRF Route Target, it identifies the corresponding MAC-VRF and imports the MAC address into it. For asymmetric IRB mode, it is assumed that all PEs participating in a tenant's VPN are configured with all subnets (i.e., all VLANs) and corresponding MAC-VRFs/BTs even if there are no locally attached TSs for some of these subnets. This is because the ingress PE needs to do forwarding based on the destination TS's MAC address and perform NVO tunnel encapsulation as the property of a lookup in the MAC-VRF/BT.
* MAC-VRFルートターゲットを使用して、対応するMAC-VRFを識別し、MACアドレスをインポートします。非対称IRBモードでは、これらのサブネットのいくつかについてローカルに接続されていなくても、テナントのVPNに参加しているすべてのPEがすべてのサブネット（すなわち、すべてのVLAN）と対応するMAC-VRFS / BTSで構成されていると仮定されます。これは、イングレスPEが宛先TSのMACアドレスに基づいて転送を行う必要があり、MAC - VRF / BT内の検索のプロパティとしてNVOトンネルカプセル化を実行する必要があるためです。
* If only the MAC-VRF Route Target is used, then the receiving PE uses the MAC-VRF Route Target to identify the corresponding IP-VRF -- i.e., many MAC-VRF Route Targets map to the same IP-VRF for a given tenant. In this case, MAC-VRF may be used by the receiving PE to identify the corresponding IP-VRF via the IRB interface associated with the subnet MAC-VRF/BT. In this case, the MAC-VRF Route Target may be used by the receiving PE to identify the corresponding IP-VRF.
* MAC-VRFルートターゲットのみが使用されている場合、受信側PEはMAC-VRFルートターゲットを使用して対応するIP-VRFを識別します。つまり、特定のテナントの場合は、多くのMAC-VRFルートターゲットが同じIP-VRFにマッピングされます。。この場合、MAC - VRFは、サブネットMAC - VRF / BTに関連するIRBインターフェースを介して対応するIP - VRFを識別するために受信PEによって使用され得る。この場合、MAC - VRFルートターゲットは、対応するIP - VRFを識別するために受信PEによって使用されてもよい。
* Using the MAC-VRF Route Target, the receiving PE identifies the corresponding ARP table or NDP cache for the tenant, and it adds an entry to the ARP table or NDP cache for the TS's MAC and IP address association. It should be noted that the tenant's ARP table or NDP cache at the receiving PE is identified by all the MAC-VRF Route Targets for that tenant.
* MAC-VRFルートターゲットを使用して、受信側PEはテナントの対応するARPテーブルまたはNDPキャッシュを識別し、TSのMACおよびIPアドレスアソシエーションのARPテーブルまたはNDPキャッシュにエントリを追加します。受信PEにおけるテナントのARPテーブルまたはNDPキャッシュは、そのテナントのすべてのMAC-VRFルートターゲットによって識別されることに注意してください。
* If the IP-VRF Route Target is included, it may be used to import the route to IP-VRF. If the IP-VRF Route Target is not included, MAC-VRF is used to derive the corresponding IP-VRF for import, as explained in the prior section. In both cases, an IP-VRF route is installed with the TS MAC binding included in the received route.
* IP-VRFルートターゲットが含まれている場合は、IP-VRFへのルートをインポートするために使用できます。IP-VRFルートターゲットが含まれていない場合は、以前のセクションで説明されているように、MAC-VRFを使用してインポート用の対応するIP-VRFを導出する。どちらの場合も、受信したルートに含まれているTS MACバインディングとともにIP-VRFルートがインストールされています。
If the receiving PE receives the MAC/IP Advertisement route with the MPLS Label2 field but the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST ignore the MPLS Label2 field and install the MAC address in the corresponding MAC-VRF and (IP, MAC) association in the ARP table or NDP cache for that tenant (with the IRB interface identified by the MAC-VRF).
受信側PEがMPLS LABEL2フィールドを使用してMAC / IPアドバタイズメントルートを受信したが、受信PEは非対称IRBモードのみをサポートしているため、受信側PEはMPLS LABLE2フィールドを無視し、対応するMAC - VRFおよび（IP）にMACアドレスをインストールする必要があります。、MAC）ARPテーブルまたはそのテナントのNDPキャッシュ（MAC-VRFによって識別されたIRBインタフェース）に関連付けられています。
When an Ethernet frame is received by an ingress PE (e.g., PE1 in Figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify the associated MAC-VRF/BT, and it performs a lookup on the destination MAC address. If the MAC address corresponds to its IRB interface MAC address, the ingress PE deduces that the packet must be inter-subnet routed. Hence, the ingress PE performs an IP lookup in the associated IP-VRF table. The lookup identifies a local adjacency to the IRB interface associated with the egress subnet's MAC-VRF/ bridge table. The ingress PE also decrements the TTL / hop limit for that packet by one, and if it reaches zero, the ingress PE discards the packet.
イーサネットネットフレームが入力PEによって（例えば、上記の図4のPE1）によって受信されると、PEはAC ID（例えばVLAN ID）を使用して関連するMAC - VRF / BTを識別し、それは宛先の検索を実行する。Macアドレス。MACアドレスがIRBインタフェースMACアドレスに対応する場合、入力PEはパケットがサブネット間ルーティングされている必要があることを推測します。したがって、入力PEは、関連するIP-VRFテーブルにIPルックアップを実行します。ルックアップは、出力サブネットのMAC-VRF / Bridgeテーブルに関連付けられているIRBインターフェイスへのローカル隣接関係を識別します。入力PEは、そのパケットのTTL / HPの制限も1つずつ減少し、ゼロに達すると、入力PEはパケットを破棄します。
The ingress PE gets the destination TS's MAC address for that TS's IP address from its ARP table or NDP cache. It encapsulates the packet with that destination MAC address and a source MAC address corresponding to that IRB interface and sends the packet to its destination subnet MAC-VRF/BT.
Ingress PEは、そのTSのIPアドレスの宛先TSのMACアドレスをARPテーブルまたはNDPキャッシュから取得します。それはその宛先MACアドレスとそのIRBインタフェースに対応する送信元MACアドレスとのパケットをカプセル化し、そのパケットをその宛先サブネットMAC - VRF / BTに送信する。
The destination MAC address lookup in the MAC-VRF/BT results in a BGP next-hop address of the egress PE along with label1 (L2 VPN MPLS label or VNI). The ingress PE encapsulates the packet using the Ethernet NVO tunnel of the choice (e.g., VXLAN or NVGRE) and sends the packet to the egress PE. Because the packet forwarding is between the ingress PE's MAC-VRF/BT and the egress PE's MAC-VRF/ bridge table, the packet encapsulation procedures follow that of [RFC7432] for MPLS and [RFC8365] for VXLAN encapsulations.
MAC - VRF / BTにおける宛先MACアドレス検索は、Label1（L2 VPN MPLS LabelまたはVNI）と共に、出力PEのBGPネクストホップアドレスをもたらす。入力PEは、選択のイーサネットNVOトンネル（例えば、VxlanまたはNVGRE）を使用してパケットをカプセル化し、そのパケットを出力PEに送信する。パケット転送は、入力PEのMAC-VRF / BTとEGRESS PEのMAC-VRF / BRIDEテーブルの間にあるため、パケットカプセル化手順はMPLSの[RFC7432]、VXLANカプセル化の場合は[RFC8365]のものです。
When a tenant's Ethernet frame is received over an NVO tunnel by the egress PE, the egress PE removes the NVO tunnel encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or VNI (for NVO encapsulation) to identify the MAC-VRF/BT in which the MAC lookup needs to be performed.
テナントのイーサネットフレームが出力PEによってNVOトンネルを介して受信されると、EGRESS PEはNVOトンネルのカプセル化を除去し、VPN MPLSラベル（MPLSカプセル化用）またはVNI（NVOカプセル化用）を使用してMAC-VRF / BTを識別します。MACルックアップを実行する必要がある。
The MAC lookup results in a local adjacency (e.g., local interface) over which the packet needs to get sent.
MACルックアップは、パケットが送信される必要があるローカル隣接（例えばローカルインタフェース）をもたらす。
Note that the forwarding behavior on the egress PE is the same as the EVPN intra-subnet forwarding described in [RFC7432] for MPLS and [RFC8365] for NVO networks. In other words, all the packet processing associated with the inter-subnet forwarding semantics is confined to the ingress PE for asymmetric IRB mode.
出力PEの転送動作は、[RFC7432]の[RFC7432]で説明されているEVPN内サブネット転送と同じです.NVOネットワーク用の[RFC8365]。つまり、サブネット間転送セマンティクスに関連するすべてのパケット処理は、非対称IRBモード用の入力PEに限定されています。
It should also be noted that [RFC7432] provides a different level of granularity for the EVPN label. Besides identifying the bridge domain table, it can be used to identify the egress interface or a destination MAC address on that interface. If an EVPN label is used for an egress interface or individual MAC address identification, then no MAC lookup is needed in the egress PE for MPLS encapsulation, and the packet can be directly forwarded to the egress interface just based on the EVPN label lookup.
[RFC7432]は、EVPNラベルに対して異なるレベルの粒状性を提供することにも注意してください。ブリッジドメインテーブルを識別するために、そのインターフェイス上の出力インタフェースまたは宛先MACアドレスを識別するために使用できます。EVPNラベルが出力インタフェースまたは個々のMACアドレス識別に使用される場合、MPLSカプセル化のために出力PEにMACルックアップは必要ありません。これは、EVPNラベル検索に基づいてパケットを出力インタフェースに直接転送できます。
When a TS moves from one NVE (aka source NVE) to another NVE (aka target NVE), it is important that the MAC Mobility procedures be properly executed and the corresponding MAC-VRF and IP-VRF tables on all participating NVEs be updated. [RFC7432] describes the MAC Mobility procedures for L2-only services for both single-homed TS and multihomed TS. This section describes the incremental procedures and BGP Extended Communities needed to handle the MAC Mobility for IRB. In order to place the emphasis on the differences between L2-only and IRB use cases, the incremental procedure is described for a single-homed TS with the expectation that the additional steps needed for a multihomed TS can be extended per Section 15 of [RFC7432]. This section describes mobility procedures for both symmetric and asymmetric IRB. Although the language used in this section is for IPv4 ARP, it equally applies to IPv6 ND.
TSがあるNVE（AKAソースNVE）から別のNVE（AKAターゲットNVE）に移動すると、MACモビリティ手順を正しく実行し、対応するMAC - VRFおよびIP-VRFテーブルがすべて更新されることが重要です。[RFC7432]シングルホームTSとマルチホームTSの両方のL2専用サービスのMACモビリティ手順を説明しています。このセクションでは、IRBのMACモビリティを処理するために必要な増分手順とBGP拡張コミュニティについて説明します。L2専用およびIRBユースケースの違いを重視するために、マルチホームTSに必要な追加のステップが[RFC7432]のセクション15あたりに延長できるという期待を有する単一のホモッドTSについての増分手順について説明する。]。このセクションでは、対称IRBと非対称IRBの両方のモビリティプロシージャについて説明します。このセクションで使用されている言語はIPv4 ARP用ですが、IPv6 NDにも同様に適用されます。
When a TS moves from a source NVE to a target NVE, it can behave in one of the following three ways:
TSがソースNVEからターゲットNVEに移動すると、次の3つの方法のいずれかで動作できます。
1. TS initiates an ARP request upon a move to the target NVE.
1. TSは、ターゲットNVEへの移動時にARP要求を開始します。
2. TS sends a data packet without first initiating an ARP request to the target NVE.
2. TSは、最初にターゲットNVEへのARP要求を開始することなくデータパケットを送信します。
3. TS is a silent host and neither initiates an ARP request nor sends any packets.
3. TSはサイレントホストであり、ARP要求も開始されたり、パケットを送信したりしません。
Depending on the expected TS's behavior, an NVE needs to handle at least the first option and should be able to handle the second and third options. The following subsections describe the procedures for each scenario where it is assumed that the MAC and IP addresses of a TS have a one-to-one relationship (i.e., there is one IP address per MAC address and vice versa). The procedures for host mobility detection in the presence of a many-to-one relationship is outside the scope of this document, and it is covered in [EXTENDED-MOBILITY]. The "many-to-one relationship" refers to many host IP addresses corresponding to a single host MAC address or many host MAC addresses corresponding to a single IP address. It should be noted that in the case of IPv6, a link-local IP address does not count in a many-to-one relationship because that address is confined to a single Ethernet segment, and it is not used for host mobility (i.e., by definition, host mobility is between two different Ethernet segments). Therefore, when an IPv6 host is configured with both a Global Unicast address (or a Unique Local address) and a link-local address, for the purpose of host mobility, it is considered with a single IP address.
予想されるTSの動作に応じて、NVEは少なくとも最初のオプションを処理する必要があり、2番目と3番目のオプションを処理できるはずです。以下のサブセクションでは、TSのMACアドレスとIPアドレスとが1対1の関係を有すると仮定されている（すなわち、MACアドレスごとに1つのIPアドレスがあり、その逆も同様である）というシナリオの手順について説明する。多対1の関係の存在下でのホスト移動度検出の手順は、この文書の範囲外であり、[拡張移動度]で覆われています。 「多対1の関係」とは、単一のホストMACアドレスまたは単一のIPアドレスに対応する多くのホストMACアドレスに対応する多くのホストIPアドレスを指す。 IPv6の場合、そのアドレスが単一のイーサネットセグメントに限定されているため、リンクローカルIPアドレスは多対1の関係ではカウントされず、ホストモビリティには使用されません（つまり、定義により、ホストモビリティは2つの異なるイーサネットセグメント間です。したがって、IPv6ホストがグローバルユニキャストアドレス（または一意のローカルアドレス）とリンクローカルアドレスの両方で設定されている場合は、ホストモビリティを目的として、単一のIPアドレスで考慮されます。
In this scenario, when a TS moves from a source NVE to a target NVE, the TS initiates a gratuitous ARP upon the move to the target NVE.
このシナリオでは、TSがソースNVEからターゲットNVEへ移動すると、TSはターゲットNVEへの移動時に無償ARPを開始する。
The target NVE, upon receiving this ARP message, updates its MAC-VRF, IP-VRF, and ARP table with the host MAC, IP, and local adjacency information (e.g., local interface).
このARPメッセージを受信すると、ターゲットNVEは、そのMAC - VRF、IP - VRF、およびARPテーブルをホストMAC、IP、およびローカル隣接情報（例えば、ローカルインタフェース）を更新する。
Since this NVE has previously learned the same MAC and IP addresses from the source NVE, it recognizes that there has been a MAC move, and it initiates MAC Mobility procedures per [RFC7432] by advertising an EVPN MAC/IP Advertisement route with both the MAC and IP addresses filled in (per Sections 5.1 and 6.1) along with the MAC Mobility extended community, with the sequence number incremented by one. The target NVE also exercises the MAC duplication detection procedure in Section 15.1 of [RFC7432].
このNVEは、ソースNVEから以前に同じMACアドレスを学んだので、MACの移動があったことを認識し、EVPN MAC / IPアドバタイズメントルートを両方のMACで広告することで[RFC7432]ごとのMACモビリティプロシージャを開始します。シーケンス番号が1つずつ増加した状態で、MACモビリティ拡張コミュニティとともに（セクション5.1および6.1）に入力されたIPアドレスとIPアドレスが入力されます。ターゲットNVEは、[RFC7432]のセクション15.1のMACの重複検出手順を実行します。
The source NVE, upon receiving this MAC/IP Advertisement route, realizes that the MAC has moved to the target NVE. It updates its MAC-VRF and IP-VRF table accordingly with the adjacency information of the target NVE. In the case of the asymmetric IRB, the source NVE also updates its ARP table with the received adjacency information, and in the case of the symmetric IRB, the source NVE removes the entry associated with the received (IP, MAC) from its local ARP table. It then withdraws its EVPN MAC/IP Advertisement route. Furthermore, it sends an ARP probe locally to ensure that the MAC is gone. If an ARP response is received, the source NVE updates its ARP entry for that (IP, MAC) and re-advertises an EVPN MAC/IP Advertisement route for that (IP, MAC) along with the MAC Mobility extended community, with the sequence number incremented by one. The source NVE also exercises the MAC duplication detection procedure in Section 15.1 of [RFC7432].
このMAC / IP広告経路を受信すると、送信元NVEは、MACがターゲットNVEに移動したことを実現する。それは、ターゲットNVEの隣接情報とそれに応じてMAC - VRFテーブルおよびIP-VRFテーブルを更新します。非対称IRBの場合、ソースNVEは受信された隣接情報でそのARPテーブルを更新し、対称IRBの場合、ソースNVEはそのローカルARPから受信した（IP、MAC）に関連するエントリを削除します。テーブル。その後、そのEVPN MAC / IPアドバタイズメントルートを引き出します。さらに、MACがなくなるように、ARPプローブをローカルに送信します。ARP応答が受信された場合、ソースNVEはそのARPエントリをその（IP、MAC）に更新し、その（IP、MAC）のためのEVPN MAC / IPアドバタイズメントルートを、そのシーケンスを持つMac Mobility Extendedコミュニティとともに再アドバタイズします。1でインクリメントされた数。ソースNVEは、[RFC7432]のセクション15.1のMAC複製検出手順を実行します。
All other remote NVE devices, upon receiving the MAC/IP Advertisement route with the MAC Mobility extended community, compare the sequence number in this advertisement with the one previously received. If the new sequence number is greater than the old one, then they update the MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF tables to point to the target NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS from the source NVE, these remote PEs perform the cleanups for their BGP tables.
他のすべてのリモートNVEデバイスは、MAC / IPアドバタイズメントルートをMACモビリティ拡張コミュニティで受信すると、この広告内のシーケンス番号を以前に受信したものと比較します。新しいシーケンス番号が古いものより大きい場合、それらはTSのMAC / IPアドレスを対応するMAC-VRFおよびIP-VRFテーブルのMAC / IPアドレスを更新して、ターゲットNVEを指すように更新します。さらに、ソースNVEからTSのMAC / IP退会を受信すると、これらのリモートPEはそれらのBGPテーブルのクリーンアップを実行します。
In this scenario, when a TS moves from a source NVE to a target NVE, the TS starts sending data traffic without first initiating an ARP request.
このシナリオでは、TSがソースNVEからターゲットNVEに移動すると、TSは最初にARP要求を開始することなくデータトラフィックの送信を開始します。
The target NVE, upon receiving the first data packet, learns the MAC address of the TS in the data plane and updates its MAC-VRF table with the MAC address and the local adjacency information (e.g., local interface) accordingly. The target NVE realizes that there has been a MAC move because the same MAC address has been learned remotely from the source NVE.
ターゲットNVEは、第1のデータパケットを受信すると、データプレーン内のTSのMACアドレスを学習し、それに応じてMACアドレスおよびローカル隣接情報（例えばローカルインタフェース）を用いてそのMAC - VRFテーブルを更新する。ターゲットNVEは、同じMACアドレスがソースNVEからリモートで学習されているため、MAC移動があることを実現しています。
If EVPN-IRB NVEs are configured to advertise MAC-only routes in addition to MAC-and-IP EVPN routes, then the following steps are taken:
EVPN-IRB NVESがMAC専用ルートをアドバタイズするように構成されている場合、MAC-AND IP EVPNルートに加えて、次の手順を実行します。
* The target NVE, upon learning this MAC address in the data plane, updates this MAC address entry in the corresponding MAC-VRF with the local adjacency information (e.g., local interface). It also recognizes that this MAC has moved and initiates MAC Mobility procedures per [RFC7432] by advertising an EVPN MAC/IP Advertisement route with only the MAC address filled in along with the MAC Mobility extended community, with the sequence number incremented by one.
* ターゲットNVEは、データプレーン内のこのMACアドレスを学習する際に、対応するMAC - VRF内のこのMACアドレスエントリを、ローカル隣接情報（例えば、ローカルインタフェース）を用いて更新する。また、このMacは、Mac Mobility Extendedコミュニティと共に埋められたMACアドレスのみを搭載したEVPN MAC / IPアドバタイズメントルートを広告し、シーケンス番号を1つインクリメントした状態で、[RFC7432]ごとにMACモビリティプロシージャを開始したことも認識しています。
* The source NVE, upon receiving this MAC/IP Advertisement route, realizes that the MAC has moved to the new NVE. It updates its MAC-VRF table with the adjacency information for that MAC address to point to the target NVE and withdraws its EVPN MAC/IP Advertisement route that has only the MAC address (if it has advertised such a route previously). Furthermore, it searches for the corresponding MAC-IP entry and sends an ARP probe for this (IP, MAC) pair. The ARP request message is sent both locally to all attached TSs in that subnet as well as to other NVEs participating in that subnet, including the target NVE. Note that the PE needs to maintain a correlation between MAC and MAC-IP route entries in the MAC-VRF to accomplish this.
* このMAC / IP広告経路を受信すると、ソースNVEは、MACが新たなNVEに移動したことを実現する。そのMACアドレスの隣接情報をターゲットNVEを指すように、MAC-VRFテーブルを更新し、MACアドレスのみを持つEVPN MAC / IPアドバタイズメントルートを引き出す（以前にそのようなルートをアドバタイズした場合）。さらに、対応するMAC-IPエントリを検索し、この（IP、MAC）ペアにARPプローブを送信します。ARP要求メッセージは、そのサブネット内のすべての接続されているTSS、ならびにそのサブネットに参加している他のNVESに、ターゲットNVEを含む他のNVSにローカルに送信されます。PEはMAC-VRFのMACとMAC-IPルートエントリ間の相関関係を維持してこれを実現する必要があります。
* The target NVE passes the ARP request to its locally attached TSs, and when it receives the ARP response, it updates its IP-VRF and ARP table with the host (IP, MAC) information. It also sends an EVPN MAC/IP Advertisement route with both the MAC and IP addresses filled in along with the MAC Mobility extended community, with the sequence number set to the same value as the one for the MAC-only Advertisement route it sent previously.
* ターゲットNVEはARP要求をローカルに接続されているTSSに渡し、ARP応答を受信すると、そのIP-VRFおよびARPテーブルとホスト（IP、MAC）情報を使用して更新します。また、Mac Mobility Extendedコミュニティとともに入力されたMACアドレスとIPアドレスの両方を持つEVPN MAC / IPアドバタイズメントルートを送信します。シーケンス番号は、それが以前に送信されたMAC専用のアドバタイズメントルートの場合と同じ値に設定されます。
* When the source NVE receives the EVPN MAC/IP Advertisement route, it updates its IP-VRF table with the new adjacency information (pointing to the target NVE). In the case of the asymmetric IRB, the source NVE also updates its ARP table with the received adjacency information, and in the case of the symmetric IRB, the source NVE removes the entry associated with the received (IP, MAC) from its local ARP table. Furthermore, it withdraws its previously advertised EVPN MAC/IP route with both the MAC and IP address fields filled in.
* ソースNVEがEVPN MAC / IPアドバタイズメントルートを受信すると、新しい隣接情報（ターゲットNVEを指す）でIP-VRFテーブルを更新します。非対称IRBの場合、ソースNVEは受信された隣接情報でそのARPテーブルを更新し、対称IRBの場合、ソースNVEはそのローカルARPから受信した（IP、MAC）に関連するエントリを削除します。テーブル。さらに、それは、MACアドレスフィールドとIPアドレスフィールドの両方を使用して、以前に広告されているEVPN MAC / IPルートを引き出します。
* All other remote NVE devices, upon receiving the MAC/IP Advertisement route with the MAC Mobility extended community, compare the sequence number in this advertisement with the one previously received. If the new sequence number is greater than the old one, then they update the MAC/IP addresses of the TS in their corresponding MAC-VRF, IP-VRF, and ARP tables (in the case of asymmetric IRB) to point to the new NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS from the old NVE, these remote PEs perform the cleanups for their BGP tables.
* 他のすべてのリモートNVEデバイスは、MAC / IPアドバタイズメントルートをMACモビリティ拡張コミュニティで受信すると、この広告内のシーケンス番号を以前に受信したものと比較します。新しいシーケンス番号が古いものより大きい場合は、新しいMAC-VRF、IP-VRF、およびARPテーブル（非対称IRBの場合）のTSのMAC / IPアドレス（非対称IRBの場合）が新しいを指すように更新されます。NVE。さらに、古いNVEからTSのMAC / IP撤回を受信すると、これらのリモートPEはそれらのBGPテーブルのクリーンアップを実行します。
If an EVPN-IRB NVE is configured not to advertise MAC-only routes, then upon receiving the first data packet, it learns the MAC address of the TS and updates the MAC entry in the corresponding MAC-VRF table with the local adjacency information (e.g., local interface). It also realizes that there has been a MAC move because the same MAC address has been learned remotely from the source NVE. It uses the local MAC route to find the corresponding local MAC-IP route and sends a unicast ARP request to the host. When receiving an ARP response, it follows the procedure outlined in Section 7.1. In the prior case, where MAC-only routes are also advertised, this procedure of triggering a unicast ARP probe at the target PE MAY also be used in addition to the source PE broadcast ARP probing procedure described earlier for better convergence.
EVPN-IRB NVEがMACのみの経路をアドバタイズしないように構成されている場合は、最初のデータパケットを受信すると、TSのMACアドレスを学習し、対応するMAC-VRFテーブル内のMACエントリをローカル隣接情報で更新します。例えば、ローカルインタフェース）。また、同じMACアドレスがソースNVEからリモートで学習されているため、MAC移動があったことも認識しています。ローカルMACルートを使用して対応するローカルMAC-IPルートを見つけて、ユニキャストARP要求をホストに送信します。ARP応答を受信すると、セクション7.1で概説されている手順に従います。MAC専用経路も広告されている以前の場合において、ターゲットPEでユニキャストARPプローブをトリガするためのこの手順は、より良い収束のために前述のソースPEブロードキャストARPプロービング手順に加えて使用され得る。
In this scenario, when a TS moves from a source NVE to a target NVE, the TS is silent, and it neither initiates an ARP request nor sends any data traffic. Therefore, neither the target nor the source NVEs are aware of the MAC move.
このシナリオでは、TSがソースNVEからターゲットNVEへ移動すると、TSはサイレントされており、それはARP要求を開始したり、データトラフィックを送信したりしません。したがって、ターゲットもソースNVEVEもMACの移動を認識していない。
On the source NVE, an age-out timer (for the silent host that has moved) is used to trigger an ARP probe. This age-out timer can be either an ARP timer or a MAC age-out timer, and this is an implementation choice. The ARP request gets sent both locally to all the attached TSs on that subnet as well as to all the remote NVEs (including the target NVE) participating in that subnet. The source NVE also withdraws the EVPN MAC/IP Advertisement route with only the MAC address (if it has previously advertised such a route).
ソースNVEでは、ADE-OUTタイマー（移動したサイレントホスト用）を使用してARPプローブをトリガーします。このエイジアウトタイマーは、ARPタイマーまたはMACエイウズアウトタイマのいずれかで、これは実装の選択です。ARP要求は、そのサブネット上のすべての添付されているTSS、およびそのサブネットに参加しているすべてのリモートNVS（ターゲットNVEを含む）をローカルに送信されます。ソースNVEはまた、MACアドレスのみを使用してEVPN MAC / IPアドバタイズメントルートを引き出す（以前にそのようなルートをアドバタイズした場合）。
The target NVE passes the ARP request to its locally attached TSs, and when it receives the ARP response, it updates its MAC-VRF, IP-VRF, and ARP table with the host (IP, MAC) and local adjacency information (e.g., local interface). It also sends an EVPN MAC/IP Advertisement route with both the MAC and IP address fields filled in along with the MAC Mobility extended community, with the sequence number incremented by one.
ターゲットNVEはARP要求をローカルに接続されているTSに渡し、ARP応答を受信すると、そのMAC-VRF、IP-VRF、およびARPテーブルがホスト（IP、MAC）、およびローカル隣接情報（など）を更新します。ローカルインタフェース）。また、Sequence Numberが1つずつ、Mac Mobility Extendedコミュニティとともに入力されたMacおよびIPアドレスフィールドの両方を持つEVPN MAC / IPアドバタイズメントルートを送信します。
When the source NVE receives the EVPN MAC/IP Advertisement route, it updates its IP-VRF table with the new adjacency information (pointing to the target NVE). In the case of the asymmetric IRB, the source NVE also updates its ARP table with the received adjacency information, and in the case of the symmetric IRB, the source NVE removes the entry associated with the received (IP, MAC) from its local ARP table. Furthermore, it withdraws its previously advertised EVPN MAC/IP route with both the MAC and IP address fields filled in.
ソースNVEがEVPN MAC / IPアドバタイズメントルートを受信すると、新しい隣接情報（ターゲットNVEを指す）でIP-VRFテーブルを更新します。非対称IRBの場合、ソースNVEは受信された隣接情報でそのARPテーブルを更新し、対称IRBの場合、ソースNVEはそのローカルARPから受信した（IP、MAC）に関連するエントリを削除します。テーブル。さらに、それは、MACアドレスフィールドとIPアドレスフィールドの両方を使用して、以前に広告されているEVPN MAC / IPルートを引き出します。
All other remote NVE devices, upon receiving the MAC/IP Advertisement route with the MAC Mobility extended community, compare the sequence number in this advertisement with the one previously received. If the new sequence number is greater than the old one, then they update the MAC/IP addresses of the TS in their corresponding MAC-VRF, IP-VRF, and ARP (in the case of asymmetric IRB) tables to point to the new NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS from the old NVE, these remote PEs perform the cleanups for their BGP tables.
他のすべてのリモートNVEデバイスは、MAC / IPアドバタイズメントルートをMACモビリティ拡張コミュニティで受信すると、この広告内のシーケンス番号を以前に受信したものと比較します。新しいシーケンス番号が古いものより大きい場合、それらは対応するMAC-VRF、IP-VRF、およびARP（非対称IRBの場合）のTSのMAC / IPアドレスを更新します。NVE。さらに、古いNVEからTSのMAC / IP撤回を受信すると、これらのリモートPEはそれらのBGPテーブルのクリーンアップを実行します。
This document defines one new BGP Extended Community for EVPN.
このドキュメントはEVPN用の新しいBGP拡張コミュニティを定義します。
A new EVPN BGP Extended Community called "EVPN Router's MAC" is introduced here. This new extended community is a transitive extended community with a Type field of 0x06 (EVPN) and a Sub-Type field of 0x03. It may be advertised along with the Encapsulation Extended Community defined in Section 4.1 of [RFC9012].
ここで「EVPNルータのMAC」と呼ばれる新しいEVPN BGP拡張コミュニティが紹介されています。この新しい拡張コミュニティは、0x06（EVPN）の型フィールドと0x03のサブタイプフィールドを持つ推移的拡張コミュニティです。[RFC9012]のセクション4.1で定義されているカプセル化拡張コミュニティと一緒に宣伝することができます。
The EVPN Router's MAC Extended Community is encoded as an 8-octet value as follows:
EVPNルータのMAC拡張コミュニティは、次のように8オクテット値としてエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x03 | EVPN Router's MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVPN Router's MAC Cont'd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EVPN Router's MAC Extended Community
図5：EVPNルータのMac Extended Community.
This extended community is used to carry the PE's MAC address for symmetric IRB scenarios, and it is sent with EVPN RT-2. The advertising PE SHALL only attach a single EVPN Router's MAC Extended Community to a route. In case the receiving PE receives more than one EVPN Router's MAC Extended Community with a route, it SHALL process the first one in the list and not store and propagate the others.
この拡張コミュニティは、対称IRBシナリオのPEのMACアドレスを運ぶために使用され、EVPN RT-2で送信されます。広告PEは、単一のEVPNルータのMAC拡張コミュニティをルートに添付するものとします。受信側PEがルートで複数のEVPNルータのMAC拡張コミュニティを受信する場合は、リスト内の最初のものを処理し、他のものを保存して伝播させるものとします。
The following sections describe two main symmetric IRB forwarding scenarios (within a DC -- i.e., intra-DC) along with the corresponding procedures. In the following scenarios, without loss of generality, it is assumed that a given tenant is represented by a single IP-VPN instance. Therefore, on a given PE, a tenant is represented by a single IP-VRF table and one or more MAC-VRF tables.
以下のセクションでは、対応する手順とともに（DC - すなわちDC内部）の2つの主対称IRB転送シナリオについて説明します。一般性を失うことなく、次のシナリオでは、特定のテナントが単一のIP-VPNインスタンスで表されていると想定されます。したがって、特定のPEでは、テナントは単一のIP-VRFテーブルと1つ以上のMAC-VRFテーブルで表されます。
This section covers the symmetric IRB procedures for the scenario where each TS is attached to one or more NVEs, and its host IP and MAC addresses are learned by the attached NVEs and are distributed to all other NVEs that are interested in participating in both intra-subnet and inter-subnet communications with that TS.
このセクションでは、各TSが1つ以上のNVEに接続されているシナリオの対称IRB手順であり、そのホストIPとMACアドレスは接続されたNVEによって学習され、両方のイントラに参加することに関心がある他のすべてのNVSに配布されます。そのTSとサブネットとサブネット間通信。
In this scenario, without loss of generality, it is assumed that NVEs operate in VLAN-based service interface mode with one bridge table(s) per MAC-VRF. Thus, for a given tenant, an NVE has one MAC-VRF for each tenant subnet (e.g., each VLAN) that is configured for extension via VXLAN or NVGRE encapsulation. In the case of VLAN-aware bundling, each MAC-VRF consists of multiple bridge tables (e.g., one bridge table per VLAN). The MAC-VRFs on an NVE for a given tenant are associated with an IP-VRF corresponding to that tenant (or IP-VPN instance) via their IRB interfaces.
このシナリオでは、一般性を失うことなく、NVEはMAC-VRFごとに1つのブリッジテーブルを使用してVLANベースのサービスインタフェースモードで動作すると仮定されます。したがって、所与のテナントの場合、NVEは、VXLANまたはNVGREカプセル化を介した拡張用に構成されている各テナントサブネット（例えば、各VLAN）に対して1つのMAC - VRFを有する。VLAN対応バンドリングの場合、各MAC - VRFは複数のブリッジテーブル（例えば、VLANごとに1つのブリッジテーブル）で構成されています。特定のテナントのNVE上のMAC-VRFは、IRBインタフェースを介してそのテナント（またはIP-VPNインスタンス）に対応するIP-VRFに関連付けられています。
Since VXLAN and NVGRE encapsulations require an inner Ethernet header (inner MAC SA/DA) and since a TS MAC address cannot be used for inter-subnet traffic, the ingress NVE's MAC address is used as an inner MAC SA. The NVE's MAC address is the device MAC address, and it is common across all MAC-VRFs and IP-VRFs. This MAC address is advertised using the new EVPN Router's MAC Extended Community (Section 8.1).
VXLANおよびNVGREのカプセル化には内側イーサネットヘッダー（内部MAC SA / DA）が必要なため、SUBNET間トラフィックにTS MACアドレスを使用できないため、インナーMAC SAとして入力NVEのMACアドレスが使用されます。NVEのMACアドレスはデバイスMACアドレスであり、すべてのMAC-VRFSとIP-VRFには一般的です。このMACアドレスは、新しいEVPNルータのMAC拡張コミュニティを使用してアドバタイズされます（セクション8.1）。
Figure 6 below illustrates this scenario, where a given tenant (e.g., an IP-VPN instance) has three subnets represented by MAC-VRF1, MAC-VRF2, and MAC-VRF3 across two NVEs. There are five TSs that are associated with these three MAC-VRFs -- i.e., TS1, TS4, and TS5 are on the same subnet (e.g., the same MAC-VRF/VLAN). TS1 and TS5 are associated with MAC-VRF1 on NVE1, while TS4 is associated with MAC-VRF1 on NVE2. TS2 is associated with MAC-VRF2 on NVE1, and TS3 is associated with MAC-VRF3 on NVE2. MAC-VRF1 and MAC-VRF2 on NVE1 are, in turn, associated with IP-VRF1 on NVE1, and MAC-VRF1 and MAC-VRF3 on NVE2 are associated with IP-VRF1 on NVE2. When TS1, TS5, and TS4 exchange traffic with each other, only the L2 forwarding (bridging) part of the IRB solution is exercised because all these TSs belong to the same subnet. However, when TS1 wants to exchange traffic with TS2 or TS3, which belong to different subnets, both the bridging and routing parts of the IRB solution are exercised. The following subsections describe the control and data plane operations for this IRB scenario in detail.
以下の図6は、所与のテナント（例えば、IP - VPNインスタンス）が2つのNVSにわたってMAC - VRF1、MAC - VRF2、およびMAC - VRF3によって表される3つのサブネットを有するこのシナリオを示す。これら3つのMAC - VRF - すなわち、TS1、TS4、およびTS5に関連付けられている5つのTSがある（例えば、同じMAC - VRF / VLAN）。 TS1とTS5はNVE1上のMAC-VRF1に関連付けられていますが、TS4はNVE2上のMAC-VRF1に関連付けられています。 TS2はNVE1上のMAC-VRF2に関連付けられており、TS3はNVE2のMAC-VRF3に関連付けられています。 NVE1上のMAC-VRF1およびMAC-VRF2は、NVE1上のIP-VRF1に関連付けられ、NVE2上のMAC-VRF1およびMAC-VRF3はNVE2のIP-VRF1に関連付けられています。 TS1、TS5、およびTS4が互いにトラフィックを交換するとき、これらのTSはすべて同じサブネットに属しているため、IRBソリューションのL2転送（ブリッジング）部分のみが実行されます。ただし、TS1がさまざまなサブネットに属するTS2またはTS3でトラフィックを交換したい場合は、IRBソリューションのブリッジング部分とルーティング部分の両方が行使されます。次のサブセクションでは、このIRBシナリオの制御とデータプレーンの動作について詳しく説明します。
NVE1 +---------+
+-------------+ | |
TS1-----| MACx| | | NVE2
(M1/IP1) |(MAC- | | | +-------------+
TS5-----| VRF1)\ | | MPLS/ | |MACy (MAC- |-----TS3
(M5/IP5) | \ | | VXLAN/ | | / VRF3) | (M3/IP3)
| (IP-VRF1)|----| NVGRE |---|(IP-VRF1) |
| / | | | | \ |
TS2-----|(MAC- / | | | | (MAC- |-----TS4
(M2/IP2) | VRF2) | | | | VRF1) | (M4/IP4)
+-------------+ | | +-------------+
| |
+---------+
Figure 6: IRB Forwarding on NVEs for Tenant Systems
図6：テナントシステム用NVSのIRB転送
Each NVE advertises a MAC/IP Advertisement route (i.e., route type 2) for each of its TSs with the following field set:
各NVEは、次のフィールドセットを使用して、各TSSのMAC / IPアドバタイズメントルート（すなわちルートタイプ2）をアドバタイズします。
* RD and Ethernet Segment Identifier (ESI) per [RFC7432]
* [RFC7432]あたりのRDおよびイーサネットセグメント識別子（ESI）
* Ethernet Tag = 0 (assuming VLAN-based service)
* イーサネットタグ= 0（VLANベースのサービスと仮定）
* MAC Address Length = 48
* MACアドレス長= 48
* MAC Address = Mi (where i = 1, 2, 3, 4, or 5) in Figure 6, above
* 上記の図6のMACアドレス= MI（i = 1,2,3,4、または5）
* IP Address Length = 32 or 128
* IPアドレス長= 32または128
* IP Address = IPi (where i = 1, 2, 3, 4, or 5) in Figure 6, above
* 上記の図6のIPアドレス= IPI（i = 1,2,3,4、または5）
* Label1 = MPLS label or VNI corresponding to MAC-VRF
* Label1 = MAC-VRFに対応するMPLSラベルまたはVNI
* Label2 = MPLS label or VNI corresponding to IP-VRF
* label2 = IP-VRFに対応するMPLSラベルまたはVNI
Each NVE advertises an EVPN RT-2 route with two Route Targets (one corresponding to its MAC-VRF and the other corresponding to its IP-VRF). Furthermore, the EVPN RT-2 is advertised with two BGP Extended Communities. The first BGP Extended Community identifies the tunnel type, and it is called "Encapsulation Extended Community" as defined in [RFC9012], and the second BGP Extended Community includes the MAC address of the NVE (e.g., MACx for NVE1 or MACy for NVE2) as defined in Section 8.1. The EVPN Router's MAC Extended Community MUST be added when the Ethernet NVO tunnel is used. If the IP NVO tunnel type is used, then there is no need to send this second Extended Community. It should be noted that the IP NVO tunnel type is only applicable to symmetric IRB procedures.
各NVEは、2つの経路ターゲット（そのMAC - VRFに対応するものとそのIP - VRFに対応するもの）を持つEVPN RT-2経路をアドバタイズします。さらに、EVPN RT-2は2つのBGP拡張コミュニティで宣伝されています。最初のBGP拡張コミュニティはトンネルタイプを識別し、[RFC9012]で定義されている「カプセル化拡張コミュニティ」と呼ばれ、2番目のBGP拡張コミュニティにはNVEのMACアドレスが含まれています（例：NVE1のMACXまたはNVE2のMACY）セクション8.1で定義されているように。Evpn RouterのMac ExtendedコミュニティをイーサネットNVOトンネルを使用すると追加する必要があります。IP NVOトンネルタイプが使用されている場合は、この2番目の拡張コミュニティを送信する必要はありません。IP NVOトンネルタイプは、対称IRB手順にのみ適用可能であることに注意してください。
Upon receiving this advertisement, the receiving NVE performs the following:
この広告を受信すると、受信NVEは次のことを実行します。
* It uses Route Targets corresponding to its MAC-VRF and IP-VRF for identifying these tables and subsequently importing the MAC and IP addresses into them, respectively.
* これらのテーブルを識別し、続いてMACアドレスとIPアドレスをそれらにインポートするためのMAC-VRFおよびIP-VRFに対応するルートターゲットを使用します。
* It imports the MAC address from the MAC/IP Advertisement route into the MAC-VRF with the BGP next-hop address as the underlay tunnel destination address (e.g., VTEP DA for VXLAN encapsulation) and label1 as the VNI for VXLAN encapsulation or an EVPN label for MPLS encapsulation.
* MAC / IPアドバタイズメントルートからMACアドレスを、BGPネクストホップアドレスをアンダーレイトンネル宛先アドレス（例えば、VTEP DA用VXLANカプセル化用）およびVXLANカプセル化またはEVPNとしてのVNIとしてのLABEL1を使用してMACアドレスをインポートします。MPLSカプセル化のラベル。
* If the route carries the new EVPN Router's MAC Extended Community and if the receiving NVE uses an Ethernet NVO tunnel, then the receiving NVE imports the IP address into IP-VRF with NVE's MAC address (from the new EVPN Router's MAC Extended Community) as the inner MAC DA, the BGP next-hop address as the underlay tunnel destination address, the VTEP DA for VXLAN encapsulation, and label2 as the IP-VPN VNI for VXLAN encapsulation.
* ルートが新しいEVPNルータのMAC拡張コミュニティを搬送し、受信NVEがイーサネットNVOトンネルを使用している場合、受信NVEは、（新しいEVPNルータのMac Extended Communityから）NVEのMACアドレスを使用してIP-VRFにIPアドレスをインポートします。インナーMAC DA、アンダーライントンネル宛先アドレス、BGPネクストホップアドレス、VXLANカプセル化用VTEP DA、およびVXLANカプセル化用のIP-VPN VNIとしてのLABEL2。
* If the receiving NVE uses MPLS encapsulation, then the receiving NVE imports the IP address into IP-VRF with the BGP next-hop address as the underlay tunnel destination address and label2 as the IP-VPN label for MPLS encapsulation.
* 受信NVEがMPLSカプセル化を使用している場合、受信NVEは、BGPエクスタウズ宛先アドレスとBGPエクスタウ宛先アドレスと、MPLSカプセル化のIP-VPNラベルとして、IPアドレスをIP-VRFにインポートします。
If the receiving NVE receives an EVPN RT-2 with only label1 and only a single Route Target corresponding to IP-VRF; an EVPN RT-2 with only a single Route Target corresponding to MAC-VRF but with both label1 and label2; or an EVPN RT-2 with a MAC address length of zero, then it MUST use the treat-as-withdraw approach [RFC7606] and SHOULD log an error message.
受信NVEがLABEL1のみでEVPN RT-2とIP-VRFに対応する単一の経路ターゲットのみを受信した場合。MAC-VRFに対応する単一の経路ターゲットのみを持つEVPN RT-2とLabel1とLabel2の両方。またはMACアドレス長がゼロのEVPN RT-2で、それは扱いAS撤回方法[RFC7606]を使用しなければならず、エラーメッセージを記録する必要があります。
The following description of the data plane operation describes just the logical functions, and the actual implementation may differ. Let's consider the data plane operation when TS1 in subnet-1 (MAC-VRF1) on NVE1 wants to send traffic to TS3 in subnet-3 (MAC-VRF3) on NVE2.
次のデータプレーン操作の説明では、論理関数だけを説明し、実際の実装は異なる場合があります。NVE1上のSUBNET-1（MAC-VRF1）のTS1がTS3にトラフィックをNVE2のTS3に送信したい場合のデータプレーン動作を検討しましょう。
* NVE1 receives a packet with the MAC DA corresponding to the MAC-VRF1 IRB interface on NVE1 (the interface between MAC-VRF1 and IP-VRF1) and the VLAN tag corresponding to MAC-VRF1.
* NVE1は、NVE1上のMAC - VRF1 IRBインタフェース（MAC - VRF1とIP - VRF1との間のインタフェース）とMAC - VRF1に対応するVLANタグを含むパケットを受信する。
* Upon receiving the packet, the NVE1 uses the VLAN tag to identify the MAC-VRF1. It then looks up the MAC DA and forwards the frame to its IRB interface.
* パケットを受信すると、NVE1はVLANタグを使用してMAC - VRF1を識別する。その後、Mac DAを調べてフレームをIRBインターフェイスに転送します。
* The Ethernet header of the packet is stripped, and the packet is fed to the IP-VRF, where an IP lookup is performed on the destination IP address. NVE1 also decrements the TTL / hop limit for that packet by one, and if it reaches zero, NVE1 discards the packet. This lookup yields the outgoing NVO tunnel and the required encapsulation. If the encapsulation is for the Ethernet NVO tunnel, then it includes the egress NVE's MAC address as the inner MAC DA, the egress NVE's IP address (e.g., BGP next-hop address) as the VTEP DA, and the VPN-ID as the VNI. The inner MAC SA and VTEP SA are set to NVE's MAC and IP addresses, respectively. If it is an MPLS encapsulation, then the corresponding EVPN and LSP labels are added to the packet. The packet is then forwarded to the egress NVE.
* パケットのイーサネットヘッダが削除され、パケットはIP-VRFに供給され、そこでIPルックアップは宛先IPアドレスで実行されます。NVE1はまたそのパケットのTTL / HPの制限を1つずつデクリメントし、ゼロに達すると、NVE1はパケットを破棄します。このルックアップは、発信NVOトンネルと必要なカプセル化をもたらします。カプセル化がイーサネットNVOトンネルの場合、内部MAC DA、出力NVEのIPアドレス（例えば、BGPネクストホップアドレス）、およびVPN-IDとしての出力NVEのMACアドレスを含む。vni。内部MAC SAとVTEP SAは、それぞれNVEのMACアドレスとIPアドレスに設定されています。MPLSカプセル化の場合は、対応するEVPNとLSPラベルがパケットに追加されます。その後、パケットは出力NVEに転送されます。
* If the egress NVE receives a packet from the Ethernet NVO tunnel (e.g., it is VXLAN encapsulated), then it removes the Ethernet header. Since the inner MAC DA is the egress NVE's MAC address, the egress NVE knows that it needs to perform an IP lookup. It uses the VNI to identify the IP-VRF table. If the packet is MPLS encapsulated, then the EVPN label lookup identifies the IP-VRF table. Next, an IP lookup is performed for the destination TS (TS3), which results in an access-facing IRB interface over which the packet is sent. Before sending the packet over this interface, the ARP table is consulted to get the destination TS's MAC address. NVE2 also decrements the TTL / hop limit for that packet by one, and if it reaches zero, NVE2 discards the packet.
* 出口NVEがイーサネットNVOトンネル（例えば、それはVXLANカプセル化されている）からパケットを受信した場合、イーサネットヘッダを削除する。内部MAC DAは出力NVEのMACアドレスであるため、出力NVEはIPルックアップを実行する必要があることを知っています。VNIを使用してIP-VRFテーブルを識別します。パケットがMPLSカプセル化されている場合、EVPNラベル検索はIP-VRFテーブルを識別します。次に、宛先TS（TS3）に対してIP検索が行われ、その結果、パケットが送信されるアクセス対向IRBインタフェースが実行される。このインタフェースを介してパケットを送信する前に、宛先TSのMACアドレスを取得するためにARPテーブルを参照してください。NVE2はまた、そのパケットのTTL / HHP制限を1つずつ減少させ、ゼロに達すると、NVE2はパケットを破棄します。
* The IP packet is encapsulated with an Ethernet header, with the MAC SA set to that of the IRB interface MAC address (i.e., the IRB interface between MAC-VRF3 and IP-VRF1 on NVE2) and the MAC DA set to that of the destination TS (TS3) MAC address. The packet is sent to the corresponding MAC-VRF (i.e., MAC-VRF3) and, after a lookup of MAC DA, is forwarded to the destination TS (TS3) over the corresponding interface.
* IPパケットはイーサネットヘッダとカプセル化され、MAC SAはIRB Interface MACアドレス（すなわち、NVE2上のMAC - VRF3とIP - VRF1との間のIRBインタフェース）と宛先のMAC DAセットに設定されている。TS（TS3）MACアドレス。パケットは対応するMAC - VRF（すなわち、MAC - VRF3）に送信され、MAC DAの検索後に対応するインターフェースを介して宛先TS（TS3）に転送される。
In this symmetric IRB scenario, inter-subnet traffic between NVEs will always use the IP-VRF VNI/MPLS label. For instance, traffic from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF VNI/ MPLS label, as long as TS4's host IP is present in NVE1's IP-VRF.
この対称IRBシナリオでは、NVS間のサブネット間トラフィックは常にIP-VRF VNI / MPLSラベルを使用します。たとえば、TS2からTS4へのトラフィックは、NVE1のIP-VRFにTS4のホストIPが存在する限り、NVE2のIP-VNI / MPLSラベルを使用してNVE1によってカプセル化されます。
This section covers the symmetric IRB procedures for the scenario where some TSs support one or more subnets and these TSs are associated with one or more NVEs. Therefore, besides the advertisement of MAC/IP addresses for each TS, which can be multihomed with All-Active redundancy mode, the associated NVE needs to also advertise the subnets statically configured on each TS.
このセクションでは、一部のTSSが1つ以上のサブネットをサポートし、これらのTSSが1つ以上のNVESに関連付けられているシナリオの対称IRB手順について説明します。したがって、全アクティブ冗長モードでマルチホーム化することができる各TSについてのMAC / IPアドレスの広告の他に、関連するNVEは各TS上で静的に設定されたサブネットをアドバタイズする必要がある。
The main difference between this solution and the previous one is the additional advertisement corresponding to each subnet. These subnet advertisements are accomplished using the EVPN IP Prefix route defined in [RFC9136]. These subnet prefixes are advertised with the IP address of their associated TS (which is in an overlay address space) as their next hop. The receiving NVEs perform recursive route resolution to resolve the subnet prefix with its advertising NVE so that they know which NVE to forward the packets to when they are destined for that subnet prefix.
この解決策と前回のものとの間の主な違いは、各サブネットに対応する追加の広告です。これらのサブネット広告は、[RFC9136]で定義されているEVPN IPプレフィックスルートを使用して実行されます。これらのサブネットプレフィックスは、関連するTS（オーバーレイアドレス空間内にある）のIPアドレスでアドレスが次のホップとしてアドレス指定されています。受信側NVEは、その広告のプレフィックスをその広告NVEで解決するために再帰的な経路解像度を実行し、そこでパケットをそのサブネットプレフィックス宛ての場合にパケットを転送するように知っている。
The advantage of this recursive route resolution is that when a TS moves from one NVE to another, there is no need to re-advertise any of the subnet prefixes for that TS. All that is needed is to advertise the IP/MAC addresses associated with the TS itself and exercise the MAC Mobility procedures for that TS. The recursive route resolution automatically takes care of the updates for the subnet prefixes of that TS.
この再帰的経路解像度の利点は、TSが1つのNVEから別のNVEに移動すると、そのTSのサブネットプレフィックスのいずれかを再アドバタイズする必要はないことです。必要なのは、TS自体に関連付けられたIP / MACアドレスをアドバタイズし、そのTSのMACモビリティ手順を宣伝することです。再帰的な経路解像度は、そのTSのサブネット接頭辞の更新を自動的に処理します。
Figure 7 illustrates this scenario where a given tenant (e.g., an IP-VPN service) has three subnets represented by MAC-VRF1, MAC-VRF2, and MAC-VRF3 across two NVEs. There are four TSs associated with these three MAC-VRFs -- i.e., TS1 is connected to MAC-VRF1 on NVE1, TS2 is connected to MAC-VRF2 on NVE1, TS3 is connected to MAC-VRF3 on NVE2, and TS4 is connected to MAC-VRF1 on NVE2. TS1 has two subnet prefixes (SN1 and SN2), and TS3 has a single subnet prefix (SN3). The MAC-VRFs on each NVE are associated with their corresponding IP-VRF using their IRB interfaces. When TS4 and TS1 exchange intra-subnet traffic, only the L2 forwarding (bridging) part of the IRB solution is used (i.e., the traffic only goes through their MAC-VRFs); however, when TS3 wants to forward traffic to SN1 or SN2 sitting behind TS1 (inter-subnet traffic), then both the bridging and routing parts of the IRB solution are exercised (i.e., the traffic goes through the corresponding MAC-VRFs and IP-VRFs). If TS4, for example, wants to reach SN1, it uses its default route and sends the packet to the MAC address associated with the IRB interface on NVE2; NVE2 then performs an IP lookup in its IP-VRF and finds an entry for SN1. The following subsections describe the control and data plane operations for this IRB scenario in detail.
図7は、所与のテナント（例えば、IP - VPNサービス）が2つのNVSにわたってMAC - VRF1、MAC - VRF2、およびMAC - VRF3によって表される3つのサブネットを有するこのシナリオを示す。これら3つのMAC-VRFSに関連するTSSがあるTSSがあります。つまり、TS1はNVE1でMAC-VRF1に接続されています.TS2はNVE1上のMAC-VRF2に接続されており、TS3はNVE2上でMAC-VRF3に接続されています。 NVE2のMAC-VRF1。 TS1には2つのサブネットプレフィックス（SN1とSN2）があり、TS3には単一のサブネットプレフィックス（SN3）があります。各NVEのMAC-VRFは、IRBインタフェースを使用して対応するIP-VRFに関連付けられています。 TS4およびTS1の交換サブネット内トラフィックの場合、IRBソリューションのL2転送（ブリッジング）部分のみが使用される（すなわち、トラフィックはそれらのMAC - VRFを通過するだけ）。ただし、TS3がTS1（サブネット間トラフィック）の背後にあるSN1またはSN2にトラフィックを転送したい場合は、IRBソリューションのブリッジング部分とルーティング部分の両方が行使されます（つまり、トラフィックは対応するMAC-VRFSとIP - を通過します。 VRFS）。たとえば、SN1に到達したい場合は、TS4がデフォルトのルートを使用し、NVE2のIRBインターフェイスに関連付けられているMACアドレスにパケットを送信します。その後、NVE2はIP-VRFでIPルックアップを実行し、SN1のエントリを見つけます。次のサブセクションでは、このIRBシナリオの制御とデータプレーンの動作について詳しく説明します。
NVE1 +----------+
SN1--+ +-------------+ | |
|--TS1-----|(MAC- \ | | |
SN2--+ M1/IP1 | VRF1) \ | | |
| (IP-VRF)|---| |
| / | | |
TS2-----|(MAC- / | | MPLS/ |
M2/IP2 | VRF2) | | VXLAN/ |
+-------------+ | NVGRE |
+-------------+ | |
SN3--+--TS3-----|(MAC-\ | | |
M3/IP3 | VRF3)\ | | |
| (IP-VRF)|---| |
| / | | |
TS4-----|(MAC- / | | |
M4/IP4 | VRF1) | | |
+-------------+ +----------+
NVE2
Figure 7: IRB Forwarding on NVEs for Subnets behind TSs
図7：TSSの背後にあるサブネットのためのNVSのIRB転送
Note that in Figure 7, above, SN1 and SN2 are configured on NVE1, which then advertises each in an IP Prefix route. Similarly, SN3 is configured on NVE2, which then advertises it in an IP Prefix route.
なお、図7では、上記の場合、SN1とSN2はNVE1上で構成されており、これはそれぞれIPプレフィックス経路でそれぞれをアドバタイズします。同様に、SN3はNVE2上で構成されており、それはそれをIPプレフィックスルートにアドバタイズします。
Each NVE advertises a route type 5 (EVPN RT-5, IP Prefix route defined in [RFC9136]) for each of its subnet prefixes with the IP address of its TS as the next hop (Gateway Address field) as follows:
各NVEは、そのTSのIPアドレスを次のホップ（ゲートウェイアドレスフィールド）として、各サブネットプレフィックスごとにルートタイプ5（RFC9136、IPプレフィックスルート）をアドバタイズします。
* RD associated with the IP-VRF
* IP-VRFに関連付けられているRD
* ESI = 0
* ESI = 0
* Ethernet Tag = 0
* イーサネットタグ= 0
* IP Prefix Length = 0 to 32 or 0 to 128
* IPプレフィックス長= 0~32または0~128
* IP Prefix = SNi
* IPプレフィックス= SNI
* Gateway Address = IPi (IP address of TS)
* ゲートウェイアドレス= IPI（TSのIPアドレス）
* MPLS Label = 0
* MPLSラベル= 0
This EVPN RT-5 is advertised with one or more Route Targets associated with the IP-VRF from which the route is originated.
このEVPN RT-5は、経路が発信されたIP-VRFに関連付けられている1つ以上のルートターゲットでアドバタイズされます。
Each NVE also advertises an EVPN RT-2 (MAC/IP Advertisement route) along with its associated Route Targets and Extended Communities for each of its TSs exactly as described in Section 9.1.1.
各NVEはまた、セクション9.1.1で説明されているように、それぞれのTSSのそれぞれのTSSについてのEVPN RT-2（MAC / IPアドバタイズメントルート）を宣伝する。
Upon receiving the EVPN RT-5 advertisement, the receiving NVE performs the following:
EVPN RT-5アドバタイズメントを受信すると、受信NVEは次のことを実行します。
* It uses the Route Target to identify the corresponding IP-VRF.
* ルートターゲットを使用して対応するIP-VRFを識別します。
* It imports the IP prefix into its corresponding IP-VRF configured with an import RT that is one of the RTs being carried by the EVPN RT-5 route, along with the IP address of the associated TS as its next hop.
* IPプレフィックスをインポートRTで構成された対応するIP-VRFに、EVPN RT-5ルートが実行中のRTSの1つであるIPアドレスとともに、関連ホップとしてのIPアドレスと共にインポートします。
When receiving the EVPN RT-2 advertisement, the receiving NVE imports the MAC/IP addresses of the TS into the corresponding MAC-VRF and IP-VRF per Section 9.1.1. When both routes exist, recursive route resolution is performed to resolve the IP prefix (received in EVPN RT-5) to its corresponding NVE's IP address (e.g., its BGP next hop). The BGP next hop will be used as the underlay tunnel destination address (e.g., VTEP DA for VXLAN encapsulation), and the EVPN Router's MAC will be used as the inner MAC for VXLAN encapsulation.
EVPN RT-2アドバタイズメントを受信すると、受信NVEはTSのMAC / IPアドレスを対応するMAC-VRFとセクション9.1.1ごとにIP-VRFにインポートします。両方の経路が存在する場合は、再帰的な経路解像度が実行され、IPプレフィックス（EVPN RT-5で受信した）を対応するNVEのIPアドレス（例えば、そのBGPネクストホップ）に解決する。BGPネクストホップは、アンダーレイトトンネル宛先アドレス（例えば、VXLANカプセル化用のVTEP DA）として使用され、EVPNルータのMACがVxLANカプセル化のための内部MACとして使用されます。
The following description of the data plane operation describes just the logical functions, and the actual implementation may differ. Let's consider the data plane operation when a host in SN1 behind TS1 wants to send traffic to a host in SN3 behind TS3.
次のデータプレーン操作の説明では、論理関数だけを説明し、実際の実装は異なる場合があります。TS1の背後にあるSN1のホストがTS3の背後にあるSN3のホストにトラフィックを送信したいときにデータプレーンの操作を検討しましょう。
* TS1 sends a packet with MAC DA corresponding to the MAC-VRF1 IRB interface of NVE1 and a VLAN tag corresponding to MAC-VRF1.
* TS1は、MAC - VRF1 IRBインタフェースに対応するMAC DAとMAC - VRF1に対応するVLANタグをパケットを送信する。
* Upon receiving the packet, the ingress NVE1 uses the VLAN tag to identify the MAC-VRF1. It then looks up the MAC DA and forwards the frame to its IRB interface as in Section 9.1.1.
* パケットを受信すると、入力NVE1はVLANタグを使用してMAC - VRF1を識別する。その後、Mac DAを調べ、セクション9.1.1のようにフレームをIRBインタフェースに転送します。
* The Ethernet header of the packet is stripped, and the packet is fed to the IP-VRF, where an IP lookup is performed on the destination address. This lookup yields the fields needed for VXLAN encapsulation with NVE2's MAC address as the inner MAC DA, NVE2's IP address as the VTEP DA, and the VNI. The MAC SA is set to NVE1's MAC address, and the VTEP SA is set to NVE1's IP address. NVE1 also decrements the TTL / hop limit for that packet by one, and if it reaches zero, NVE1 discards the packet.
* パケットのイーサネットヘッダが削除され、パケットはIP-VRFに供給され、そこでIPルックアップは宛先アドレスで実行されます。このルックアップは、内部MAC DA、NVE2のIPアドレス、VTEP DA、およびVNIとして、NVE2のMACアドレスを使用したVXLANカプセル化に必要なフィールドをもたらします。MAC SAはNVE1のMACアドレスに設定され、VTEP SAはNVE1のIPアドレスに設定されています。NVE1はまたそのパケットのTTL / HPの制限を1つずつデクリメントし、ゼロに達すると、NVE1はパケットを破棄します。
* The packet is then encapsulated with the proper header based on the above info and is forwarded to the egress NVE (NVE2).
* その後、パケットは上記の情報に基づいて適切なヘッダとカプセル化され、出力NVE（NVE2）に転送されます。
* On the egress NVE (NVE2), assuming the packet is VXLAN encapsulated, the VXLAN and the inner Ethernet headers are removed, and the resultant IP packet is fed to the IP-VRF associated with that VNI.
* 出力NVE（NVE2）では、パケットがVXLANカプセル化されていると仮定すると、VXLANと内部イーサネットヘッダーが削除され、結果のIPパケットはそのVNIに関連付けられているIP-VRFに供給されます。
* Next, a lookup is performed based on the IP DA (which is in SN3) in the associated IP-VRF of NVE2. The IP lookup yields the access-facing IRB interface over which the packet needs to be sent. Before sending the packet over this interface, the ARP table is consulted to get the destination TS (TS3) MAC address. NVE2 also decrements the TTL / hop limit for that packet by one, and if it reaches zero, NVE2 discards the packet.
* 次に、NVE2のIP - VRFのIP DA（SN3にある）に基づいてルックアップが行われる。IPルックアップは、パケットを送信する必要があるアクセスに直面しているIRBインタフェースをもたらします。このインターフェイスを介してパケットを送信する前に、ARPテーブルを参照して宛先TS（TS3）MACアドレスを取得します。NVE2はまた、そのパケットのTTL / HHP制限を1つずつ減少させ、ゼロに達すると、NVE2はパケットを破棄します。
* The IP packet is encapsulated with an Ethernet header with the MAC SA set to that of the access-facing IRB interface of the egress NVE (NVE2), and the MAC DA is set to that of the destination TS (TS3) MAC address. The packet is sent to the corresponding MAC-VRF3 and, after a lookup of MAC DA, is forwarded to the destination TS (TS3) over the corresponding interface.
* IPパケットは、出口NVE（NVE2）のアクセス対向IRBインターフェースのアクセス対向IRBインターフェースのMAC SAを用いてイーサネットヘッダをカプセル化しており、MAC DAは宛先TS（TS3）MACアドレスのそれに設定されている。パケットは対応するMAC - VRF3に送信され、MAC DAの検索後に対応するインタフェースを介して宛先TS（TS3）に転送される。
The security considerations for Layer 2 forwarding in this document follow those of [RFC7432] for MPLS encapsulation and those of [RFC8365] for VXLAN or NVGRE encapsulations. This section describes additional considerations.
この文書のレイヤ2転送のセキュリティ上の考慮事項は、MPLSカプセル化のための[RFC7432]のもの、およびVXLANまたはNVGREのカプセル化のための[RFC8365]のものに続きます。この項では、その他の考慮事項について説明します。
This document describes a set of procedures for inter-subnet forwarding of tenant traffic across PEs (or NVEs). These procedures include both Layer 2 forwarding and Layer 3 routing on a packet-by-packet basis. The security consideration for Layer 3 routing in this document follows that of [RFC4365], with the exception of the application of routing protocols between CEs and PEs. Contrary to [RFC4364], this document does not describe route distribution techniques between CEs and PEs but rather considers the CEs as TSs or VAs that do not run dynamic routing protocols. This can be considered a security advantage, since dynamic routing protocols can be blocked on the NVE/PE ACs, not allowing the tenant to interact with the infrastructure's dynamic routing protocols.
この文書では、PES（またはNVES）間のテナントトラフィックのサブネット間転送のための一連の手順を説明しています。これらの手順には、パケットごとに、レイヤ2の転送とレイヤ3の両方のルーティングが含まれます。この文書のレイヤ3ルーティングのセキュリティ検討は、CEとPES間のルーティングプロトコルの適用を除いて、[RFC4365]のセキュリティ検討に従います。[RFC4364]に反して、この文書はCESとPEの間の経路配布技術を説明していませんが、むしろ動的ルーティングプロトコルを実行しないTSSまたはVASとしてCESを考慮しています。動的ルーティングプロトコルはNVE / PE ACSでブロックされる可能性があるため、これはセキュリティ上の優位性と見なすことができます。これは、テナントがインフラストラクチャの動的ルーティングプロトコルと対話できるようになりました。
The VPN scheme described in this document does not provide the quartet of security properties mentioned in [RFC4365] (confidentiality protection, source authentication, integrity protection, and replay protection). If these are desired, they must be provided by mechanisms that are outside the scope of the VPN mechanisms.
この文書に記載されているVPNスキームは、[RFC4365]（機密保護、ソース認証、整合性保護、および再生保護）に記載されているセキュリティプロパティの四分項はありません。これらが望まれる場合は、VPNメカニズムの範囲外のメカニズムによって提供されなければなりません。
In this document, the EVPN RT-5 is used for certain scenarios. This route uses an Overlay Index that requires a recursive resolution to a different EVPN route (an EVPN RT-2). Because of this, it is worth noting that any action that ends up filtering or modifying the EVPN RT-2 route used to convey the Overlay Indexes will modify the resolution of the EVPN RT-5 and therefore the forwarding of packets to the remote subnet.
この文書では、EVPN RT-5は特定のシナリオに使用されます。このルートは、異なるEVPNルート（EVPN RT-2）に対して再帰的解像度を必要とするオーバーレイインデックスを使用します。このため、オーバーレイインデックスを伝えるために使用されるEVPN RT-2ルートのフィルタリングまたは変更を終わらせるアクションは、EVPN RT-5の解像度、したがってリモートサブネットへのパケットの転送を変更することがわかります。
IANA has allocated Sub-Type value 0x03 in the "EVPN Extended Community Sub-Types" registry as follows:
IANAは、次のように「EVPN拡張コミュニティサブタイプ」レジストリにサブタイプ値0x03を割り当てました。
+================+======================================+===========+
| Sub-Type Value | Name | Reference |
+================+======================================+===========+
| 0x03 | EVPN Router's MAC | RFC 9135 |
| | Extended Community | |
+----------------+--------------------------------------+-----------+
Table 1
表1
This document has been listed as an additional reference for the MAC/ IP Advertisement route in the "EVPN Route Types" registry.
この文書は、「EVPN Route Types」レジストリのMac / IPアドバタイズメントルートの追加の参照としてリストされています。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[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>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW.HenderickX、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https：//www.rfc-editor.org/info/rfc7432>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK。Patel、「BGP更新メッセージの修正エラー処理」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>.
[RFC8365] Sajassi、A.、ED。、Drake、J.、Ed。、Bitar、N.、Shekhar、R.、Uttaro、J.、およびW.HenderickX、「イーサネットVPNを使用したネットワーク仮想化オーバーレイソリューション（EVPN） "、RFC 8365、DOI 10.17487 / RFC8365、2018年3月、<https：//www.rfc-editor.org/info/rfc8365>。
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9012]聖母、K.、Van de Velde、G.、Sangli、S.、およびJ.Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487 / RFC9012、2021年4月、<https：// www.rfc-editor.org / info / rfc9012>。
[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>.
[RFC9136]ラバダン、J.、ED。、Henderickx、W.、Drake、J.、Lin、W.、およびA.Sajassi、「イーサネットVPN（EVPN）のIPプレフィックス広告」、RFC 9136、DOI 10.17487 / RFC91362021年10月、<https://www.rfc-editor.org/info/rfc9136>。
[EVPN] Krattiger, L., Ed., Sajassi, A., Ed., Thoria, S., Rabadan, J., and J. Drake, "EVPN Interoperability Modes", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-modes-interop-00, 26 May 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-modes-interop-00>.
[EVPN] Krattiger、L.、Ed。、Sajassi、A.、ED。、Thoria、S.、Rabadan、J.、J. Drake、 "Evpn Interoperability Modes"、進行中の作業、インターネットドラフト、ドラフト - IETF-BESS-EVPN-Modes-Interop-00,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-vess-evpn-modes-InterOp-00>。
[EXTENDED-MOBILITY] Malhotra, N., Ed., Sajassi, A., Pattekar, A., Rabadan, J., Lingala, A., and J. Drake, "Extended Mobility Procedures for EVPN-IRB", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-irb-extended-mobility-07, 2 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-07>.
[拡張モビリティ] Malhotra、N.、Ed。、Sajassi、A.、Pattekar、A.、Rabadan、J.、Lingala、A.、J. Drake、「EVPN-IRBの拡張モビリティ手順」、働く進捗状況、インターネットドラフト、ドラフト-IETF-BESS-EVPN-IRB-Extended-Mobility-07,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-vess-evpn-irb-Extended-Mobility-07>。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, <https://www.rfc-editor.org/info/rfc4365>.
[RFC4365]ローゼン、E。、「BGP / MPLS IP仮想プライベートネットワーク（VPNS / MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4365、DOI 10.17487 / RFC4365、2006年2月、<https：//www.rfc-editor.org/info/RFC4365>。
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.
[RFC5798] NADAS、S、ED。、「IPv4およびIPv6のVRRP）バージョン3、RFC 5798、DOI 10.17487 / RFC5798、2010年3月、<https：//www.rfc-editor.org/ info / rfc5798>。
[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>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M.、およびC.ライト「仮想拡張ローカルエリアネットワーク（VXLAN）：Layer 3ネットワーク上の仮想化レイヤ2ネットワークを重ねるフレームワーク「RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https：//www.rfc-editor.org/info/rfc7348>。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N.、Y.Rekhter、 "データセンターのフレームワーク（DC）ネットワーク仮想化"、RFC 7365、DOI 10.17487 / RFC7365、2014年10月<https：//www.rfc-editor.org/info/rfc7365>。
[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>.
[RFC7637] Garg、P.、ED。Y。、「NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https：//www.rfc-editor.org/info/rfc7637>。
[VXLAN-GPE] Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed., "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-nvo3-vxlan-gpe-12>.
[VXLAN-GPE]メインロ、F.、ED。、KREEGER、L.、ED。、およびU. Elzur、ED。、「VXLAN（VXLAN-GPEの一般的なプロトコル拡張」、進行中の作業、インターネットドラフト、draft-ietf-nvo3-vxlan-gpe-12,209月22日、<https://datatracker.ietf.org/doc/html/ romft-ietf-nvo3-vxlan-gpe-12>。
Acknowledgements
謝辞
The authors would like to thank Sami Boutros, Jeffrey Zhang, Krzysztof Szarkowicz, Lukas Krattiger and Neeraj Malhotra for their valuable comments. The authors would also like to thank Linda Dunbar, Florin Balus, Yakov Rekhter, Wim Henderickx, Lucy Yong, and Dennis Cai for their feedback and contributions.
著者らは、Sami Boutros、Jeffrey Zhang、Krzysztof Szarkowicz、Lukas Krattiger、およびNeeraj Malhotraに貴重なコメントをお寄せいただきありがとうございます。著者らは、リンダ・ダンバー、フロリンバー・フロウス、ヤコフ・レッカー、Wim Henderickx、Lucy Yong、およびDennis Caiに、フィードバックと貢献をしています。
Authors' Addresses
著者の住所
Ali Sajassi Cisco Systems
Ali Sajassi Cisco Systems.
Email: sajassi@cisco.com
Samer Salam Cisco Systems
サマーサラムシスコシステムズ
Email: ssalam@cisco.com
Samir Thoria Cisco Systems
Samir Thoria Cisco Systems.
Email: sthoria@cisco.com
John E Drake Juniper
ジョンeドレイクジュイパー
Email: jdrake@juniper.net
Jorge Rabadan Nokia
ジョージラバダンノキア
Email: jorge.rabadan@nokia.com