Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 10039 Nokia
Category: Standards Track A. Sajassi, Ed.
ISSN: 2070-1721 Cisco
J. Drake
Independent
W. Lin
HPE
J. Uttaro
Independent
A. Simpson
Nokia
September 2026
Ethernet Virtual Private Network (EVPN) provides a unified BGP control plane for both intra- and inter-subnet forwarding within tenant networks. When a tenant network spans multiple domains, including any combination of EVPN and IPVPN domains, it becomes necessary to define the interworking mechanisms among these BGP domains (EVPN and IPVPN) to ensure seamless end-to-end tenant connectivity. This document defines these interworking procedures.
イーサネット仮想プライベート ネットワーク (EVPN) は、テナント ネットワーク内のサブネット内およびサブネット間の両方の転送に統合 BGP コントロール プレーンを提供します。テナント ネットワークが EVPN ドメインと IPVPN ドメインの任意の組み合わせを含む複数のドメインにまたがる場合、シームレスなエンドツーエンドのテナント接続を確保するために、これらの BGP ドメイン (EVPN と IPVPN) 間のインターワーキング メカニズムを定義する必要があります。この文書では、これらの相互作用手順を定義します。
In addition, this document defines a new BGP Path Attribute, referred to as Domain Path (D-PATH), which provides loop prevention for gateway nodes by protecting against control plane loops. The introduction of D-PATH modifies the BGP best-path selection process for Multiprotocol BGP inter-subnet forwarding (ISF) routes of Subsequent Address Family Identifiers (SAFIs) 128 (IPVPN) and 70 (EVPN).
さらに、このドキュメントでは、ドメイン パス (D-PATH) と呼ばれる新しい BGP パス属性を定義します。これは、コントロール プレーン ループから保護することにより、ゲートウェイ ノードにループ防止を提供します。D-PATH の導入により、後続アドレス ファミリ識別子 (SAFI) 128 (IPVPN) および 70 (EVPN) のマルチプロトコル BGP サブネット間転送 (ISF) ルートの BGP ベスト パス選択プロセスが変更されます。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10039.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10039 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction and Problem Statement
2. Conventions Used in This Document
3. Terminology and Interworking PE Components
4. Domain Path (D-PATH) Attribute
5. BGP Path Attribute Propagation Across Domains
5.1. No Propagation Mode
5.2. Uniform Propagation Mode
5.3. Aggregation of Routes and Path Attribute Propagation
6. Route Selection Process for ISF Routes
6.1. Tie-Breaking and Selection Rules
6.2. Examples
7. Composite PE Procedures
8. Gateway PE Procedures
8.1. Export Conditions
8.2. Advertisement Behavior
9. Interworking Use Cases
10. BGP Error Handling on Interworking PEs
11. Security Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
EVPN is used as a unified BGP control plane to support both intra-and inter-subnet forwarding for tenant networks. In deployments where a tenant network spans multiple domains, some that use EVPN and others that rely on BGP VPN-IPv4/VPN-IPv6 address families for inter-subnet forwarding (ISF), it becomes necessary to define interworking procedures to enable seamless end-to-end tenant connectivity across these heterogeneous domains.
EVPN は、テナント ネットワークのサブネット内およびサブネット間の両方の転送をサポートする統合 BGP コントロール プレーンとして使用されます。テナント ネットワークが複数のドメインにまたがる展開では、EVPN を使用するドメインとサブネット間転送 (ISF) に BGP VPN-IPv4/VPN-IPv6 アドレス ファミリに依存するドメインがあり、これらの異種ドメイン間でシームレスなエンドツーエンドのテナント接続を可能にするインターワーキング手順を定義する必要があります。
This document specifies procedures for interworking between EVPN and other BGP address families, including VPN-IPv4 and VPN-IPv6, for the purpose of ISF. It also defines procedures for the interconnection of domains that may use EVPN, IPVPN, or a combination of both. Examples include the interconnection of two EVPN domains, two IPVPN domains, or an EVPN domain with an IPVPN domain.
このドキュメントでは、ISF を目的として、EVPN と VPN-IPv4 および VPN-IPv6 を含む他の BGP アドレス ファミリとの間のインターワーキング手順を指定します。また、EVPN、IPVPN、または両方の組み合わせを使用するドメインの相互接続の手順も定義します。例には、2 つの EVPN ドメイン、2 つの IPVPN ドメイン、または EVPN ドメインと IPVPN ドメインの相互接続が含まれます。
To support loop prevention in scenarios where redundant gateway Provider Edges (PEs) interconnect distinct domains, this specification introduces a new BGP Path Attribute called the Domain Path (D-PATH). In topologies where multiple gateways connect domains, control plane loops may occur if routes are redistributed between domains without proper safeguards. For example, if gateway PE1 imports an IPVPN route for a given prefix and redistributes it as an EVPN IP Prefix route into the EVPN domain, and a second gateway PE2 receives this EVPN route and re-advertises it back into the IPVPN domain, a loop may form. The D-PATH Path Attribute is designed to prevent such scenarios by providing domain-level loop detection and avoidance.
冗長ゲートウェイ プロバイダー エッジ (PE) が個別のドメインを相互接続するシナリオでループ防止をサポートするために、この仕様では、ドメイン パス (D-PATH) と呼ばれる新しい BGP パス属性を導入しています。複数のゲートウェイがドメインに接続するトポロジでは、適切な保護策なしでルートがドメイン間で再配布されると、コントロール プレーン ループが発生する可能性があります。たとえば、ゲートウェイ PE1 が特定のプレフィックスの IPVPN ルートをインポートし、EVPN IP プレフィックス ルートとして EVPN ドメインに再配布し、2 番目のゲートウェイ PE2 がこの EVPN ルートを受信して IPVPN ドメインに再アドバタイズすると、ループが形成される可能性があります。D-PATH パス属性は、ドメイン レベルのループ検出と回避を提供することで、このようなシナリオを防ぐように設計されています。
The D-PATH Path Attribute alters the BGP best-path selection logic for Multiprotocol BGP routes of SAFI 128 (VPN-IPv4/IPv6) and for EVPN IP Prefix routes. Accordingly, this document updates the BGP best-path selection procedures specified in [RFC4271], but only for the IPVPN and EVPN families when the D-PATH Path Attribute is used for inter-domain connectivity.
D-PATH パス属性は、SAFI 128 (VPN-IPv4/IPv6) のマルチプロトコル BGP ルートおよび EVPN IP プレフィックス ルートの BGP ベスト パス選択ロジックを変更します。したがって、この文書は、[RFC4271] で指定されている BGP ベストパス選択手順を更新しますが、D-PATH パス属性がドメイン間接続に使用される場合の IPVPN および EVPN ファミリのみを対象としています。
EVPN supports the advertisement of IPv4 or IPv6 prefixes through two route types:
EVPN は、次の 2 つのルート タイプを通じて IPv4 または IPv6 プレフィックスのアドバタイズメントをサポートします。
* Route Type 2 - EVPN MAC / IP Advertisement route, as defined in [RFC9135], supporting host routes (i.e., /32 or /128).
* ルート タイプ 2 - [RFC9135] で定義されている、ホスト ルート (つまり、/32 または /128) をサポートする EVPN MAC / IP アドバタイズメント ルート。
* Route Type 5 - EVPN IP Prefix route, as defined in [RFC9136].
* ルート タイプ 5 - [RFC9136] で定義されている EVPN IP プレフィックス ルート。
When interworking with other BGP address families for inter-subnet forwarding, the IP prefixes conveyed in these EVPN route types are re-originated into corresponding address families (e.g., IPVPN), and vice versa. Several aspects of this re-origination require clarified procedures, including route selection, loop prevention, and BGP Path Attribute handling across AFI/SAFI boundaries.
サブネット間転送のために他の BGP アドレス ファミリと相互作用する場合、これらの EVPN ルート タイプで伝達される IP プレフィックスは、対応するアドレス ファミリ (IPVPN など) に再生成され、その逆も同様です。この再発信のいくつかの側面では、ルート選択、ループ防止、AFI/SAFI 境界を越える BGP パス属性の処理など、明確化された手順が必要です。
This document defines the concept of an Interworking PE (Section 3), which is responsible for interconnecting different domains. An Interworking PE implements the following behavior: It imports routes from one domain (along with the domain-specific encapsulation parameters), installs them in an IP Virtual Routing and Forwarding (IP-VRF) table [RFC9135], and re-originates the routes with the encapsulation attributes suitable for the adjacent domain before advertisement. This re-origination process enables the solution to operate independently of the transport encapsulation mechanisms used within each domain and serves as a service interworking function.
この文書は、異なるドメインの相互接続を担うインターワーキング PE の概念を定義します (セクション 3)。インターワーキング PE は、次の動作を実装します。 1 つのドメインからルートを (ドメイン固有のカプセル化パラメータとともに) インポートし、それらを IP 仮想ルーティングおよび転送 (IP-VRF) テーブル [RFC9135] にインストールし、アドバタイズ前に隣接するドメインに適したカプセル化属性を持つルートを再生成します。この再発信プロセスにより、ソリューションは各ドメイン内で使用されるトランスポート カプセル化メカニズムから独立して動作できるようになり、サービス インターワーキング機能として機能します。
The procedures defined herein ensure that tenant inter-subnet connectivity can be maintained across a mix of EVPN and non-EVPN domains, while preventing routing loops and maintaining protocol consistency across BGP address families.
ここで定義された手順により、ルーティング ループを防止し、BGP アドレス ファミリ全体でプロトコルの一貫性を維持しながら、EVPN ドメインと非 EVPN ドメインの混在にわたってテナントのサブネット間接続を維持できることが保証されます。
As a summary, the following key procedures are specified by this document:
要約として、この文書では次の主要な手順が指定されています。
* A route selection algorithm that enables a PE to deterministically select the best path among candidates learned via EVPN and other ISF SAFIs.
* PE が EVPN および他の ISF SAFI 経由で学習した候補の中から最適なパスを決定的に選択できるようにするルート選択アルゴリズム。
* A new BGP Path Attribute, referred to as the D-PATH Path Attribute, which provides loop prevention capabilities and conveys domain traversal information for a given route.
* D-PATH パス属性と呼ばれる新しい BGP パス属性。ループ防止機能を提供し、特定のルートのドメイン トラバーサル情報を伝達します。
* The rules governing BGP Path Attribute propagation across domains to maintain semantic consistency and enable cross-domain route processing.
* セマンティックの一貫性を維持し、クロスドメインのルート処理を可能にするために、ドメイン間での BGP パス属性の伝播を管理するルール。
* The operational procedures required for Interworking PEs that function as composite PEs, gateway PEs, or devices supporting both roles.
* 複合 PE、ゲートウェイ PE、または両方の役割をサポートするデバイスとして機能するインターワーキング PE に必要な操作手順。
Collectively, these procedures equip operators with the necessary mechanisms to deploy scalable tenant networks spanning multiple administrative or routing domains, employing different ISF SAFIs for IP prefix dissemination while maintaining deterministic forwarding behavior and routing loop protection.
これらの手順をまとめると、オペレータは複数の管理ドメインまたはルーティング ドメインにまたがるスケーラブルなテナント ネットワークを展開するために必要なメカニズムを備え、決定的な転送動作とルーティング ループ保護を維持しながら、IP プレフィックス配布にさまざまな ISF SAFI を採用します。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section summarizes the terminology related to the "Interworking PE" concept that will be used throughout the rest of the document.
このセクションでは、本書の残りの部分で使用される「インターワーキング PE」の概念に関連する用語を要約します。
+-------------------------------------------------------------+
| |
| +------------------+ Interworking PE |
| Attachment | +------------------+ |
| Circuit (AC1)| | +----------+ | MPLS/NVO/SRv6 tnl
----------------------*Bridge | | +------
MPLS/NVO | | |Table(BT1)| | +-----------+ / \ \
/SRv6 tnl +-------->| *---------* |<--> | Eth |
-------+ | | | |Eth-Tag x | |IRB1| | \ / /
/ Eth / \<-+ | | +----------+ | | | +------
| | | | | ... | | IP-VRF1 |MPLS/NVO/SRv6
\ \ /<-+ | | +----------+ | | RD2/RT2 | tnl
-------+ | | | |Bridge | | | | +------
| +-------->|Table(BT2)| |IRB2| | / \ \
| | | | *---------* |<--> | IP |
----------------------*Eth-Tag y | | +-----*-----+ \ / /
| AC2 | | +----------+ | AC3| +------
| | | MAC-VRF1 | | |
| +-+ RD1/RT1 | | |
| +------------------+ | SAFIs |
| | IPVPN +---+ |
-------------------------------------------------+ EVPN |BGP| |
| IP +---+ |
| |
+-------------------------------------------------------------+
Figure 1: EVPN-IPVPN Interworking PE
図 1: EVPN-IPVPN インターワーキング PE
Note: "tnl" refers to "tunnel".
注: 「tnl」は「トンネル」を指します。
AC:
AC:
An Attachment Circuit or logical interface associated to a given Bridge Table (BT) or IP-VRF. To determine the AC on which a packet arrived, the PE will examine the combination of a physical port and VLAN tags (where the VLAN tags can be individual VLAN tags, Q-in-Q tags, or ranges of both).
特定のブリッジ テーブル（BT）または IP-VRF に関連付けられた接続回線または論理インターフェイス。パケットが到着した AC を判断するために、PE は物理ポートと VLAN タグの組み合わせを調べます (VLAN タグは、個々の VLAN タグ、Q-in-Q タグ、または両方の範囲にすることができます)。
Example: In Figure 1, AC1 is associated to BT1, AC2 to BT2, and AC3 to IP-VRF1.
例：図 1 では、AC1 は BT1 に、AC2 は BT2 に、AC3 は IP-VRF1 に関連付けられています。
BT:
BT:
A Bridge Table, as defined in [RFC7432], represents the instantiation of a broadcast domain on a PE. When an EVPN Instance (EVI) contains a single broadcast domain, the associated MAC-VRF on each PE includes a single BT. In cases where multiple Broadcast Domains exist within the same MAC-VRF, each BT is associated with a distinct Ethernet Tag. EVPN routes specific to a given BT include the corresponding Ethernet Tag to indicate the broadcast domain to which the route pertains.
[RFC7432] で定義されているブリッジ テーブルは、PE 上のブロードキャスト ドメインのインスタンス化を表します。EVPN インスタンス (EVI) に単一のブロードキャスト ドメインが含まれる場合、各 PE 上の関連する MAC-VRF には単一の BT が含まれます。同じ MAC-VRF 内に複数のブロードキャスト ドメインが存在する場合、各 BT は個別のイーサネット タグに関連付けられます。特定の BT に固有の EVPN ルートには、ルートが関係するブロードキャスト ドメインを示す対応するイーサネット タグが含まれます。
Example: In Figure 1, MAC-VRF1 has two BTs: BT1 and BT2. Ethernet Tag x is defined in BT1 and Ethernet Tag y in BT2.
例: 図 1 では、MAC-VRF1 には BT1 と BT2 という 2 つの BT があります。イーサネット タグ x は BT1 で定義され、イーサネット タグ y は BT2 で定義されます。
CE:
CE:
A Customer Edge device.
カスタマーエッジデバイス。
Composite Domain:
複合ドメイン:
A domain in which multiple control plane ISF SAFIs, i.e., IPVPN and/or EVPN, are used and that is composed of regular PEs and composite PEs; see below.
複数のコントロール プレーン ISF SAFI、つまり IPVPN や EVPN が使用され、通常の PE と複合 PE で構成されるドメイン。以下を参照してください。
Composite PE:
複合PE:
An Interworking PE that is connected to at least one composite domain and is capable of advertising a given prefix to multiple types of peers using appropriate route types. Specifically, a composite PE advertises the prefix to an IPVPN peer using an IPVPN ISF route, to an EVPN peer using an EVPN ISF route, and to a Route Reflector (RR) [RFC4456] using both IPVPN and EVPN ISF routes (assuming the same RR is used for IPVPN and EVPN). A composite PE implements the procedures defined in Section 7.
少なくとも 1 つの複合ドメインに接続され、適切なルート タイプを使用して特定のプレフィックスを複数のタイプのピアにアドバタイズできるインターワーキング PE。具体的には、複合 PE は、IPVPN ISF ルートを使用して IPVPN ピアにプレフィックスをアドバタイズし、EVPN ISF ルートを使用して EVPN ピアにプレフィックスをアドバタイズし、IPVPN と EVPN ISF ルートの両方を使用してルート リフレクター (RR) [RFC4456] にプレフィックスをアドバタイズします (IPVPN と EVPN に同じ RR が使用されていると仮定します)。複合 PE は、セクション 7 で定義されたプロシージャを実装します。
Example: Figure 2 illustrates a scenario where PE1 is a composite PE, as PE1 has both EVPN and IPVPN enabled toward the same RR. PE1 advertises a given IP prefix (IPn/x) twice: once using EVPN and once using IPVPN. PE2 and PE3 are not composite PEs.
例: 図 2 は、PE1 が同じ RR に対して EVPN と IPVPN の両方を有効にしているため、PE1 が複合 PE であるシナリオを示しています。PE1 は、指定された IP プレフィックス (IPn/x) を 2 回アドバタイズします。1 回目は EVPN を使用し、もう 1 回目は IPVPN を使用します。PE2 と PE3 は複合 PE ではありません。
+---+
|PE2|
+---+
^
Interworking |EVPN
PE EVPN v
+---+ IPVPN +--+ +---+
|PE1| <----> |RR| <---> |PE3|
+---+ +--+ IPVPN +---+
Composite
Figure 2: Interworking Composite PE Example
図 2: インターワーキング複合 PE の例
Composite/Gateway PE:
コンポジット/ゲートウェイ PE:
An Interworking PE that simultaneously performs the functions of both a composite PE and a gateway PE. This type of PE is connected to two or more domains: one or more regular domains and one or more composite domains. It operates as follows:
複合 PE とゲートウェイ PE の両方の機能を同時に実行するインターワーキング PE。このタイプの PE は、2 つ以上のドメイン (1 つ以上の通常のドメインと 1 つ以上の複合ドメイン) に接続されます。次のように動作します。
* Re-originates an ISF route received from the regular domain into the composite domain. Within the composite domain, it performs the behavior of a composite PE.
* 通常のドメインから受信した ISF ルートを複合ドメインに再発信します。複合ドメイン内では、複合 PE の動作を実行します。
* Re-originates an ISF route received from the composite domain into the regular domain. In the regular domain, the route is advertised using the ISF SAFI applicable to that domain.
* 複合ドメインから受信した ISF ルートを通常のドメインに再発信します。通常のドメインでは、ルートはそのドメインに適用される ISF SAFI を使用してアドバタイズされます。
This functionality is particularly useful in scenarios where a tenant network spans multiple domains using different ISF SAFIs (e.g., IPVPN and EVPN) and where any-to-any tenant connectivity is required. In such deployments, maintaining consistent end-to-end control plane behavior across domains is desirable when feasible.
この機能は、テナント ネットワークが異なる ISF SAFI (IPVPN や EVPN など) を使用して複数のドメインにまたがる場合や、任意のテナント間の接続が必要なシナリオで特に役立ちます。このような展開では、可能な場合には、ドメイン間で一貫したエンドツーエンドのコントロール プレーンの動作を維持することが望ましいです。
Example: Figure 3 illustrates a scenario where PE1 is a composite/ gateway PE.
例: 図 3 は、PE1 が複合/ゲートウェイ PE であるシナリオを示しています。
+---+
|PE2|
+---+
^
Interworking |EVPN
PE EVPN v
+---+ EVPN +---+ IPVPN +--+ +---+
|PE4| <----> |PE1| <----> |RR| <---> |PE3|
+---+ +---+ +--+ IPVPN +---+
Composite/Gateway
Figure 3: Interworking Composite/Gateway PE Example
図 3: インターワーキングコンポジット/ゲートウェイ PE の例
Domain:
ドメイン：
Two PEs belong to the same domain if they are attached to the same tenant and the packets exchanged between them do not require a data-path IP lookup (in the tenant space) at any transit router. A gateway PE interconnects multiple DOMAIN-IDs. Domain boundaries are not restricted to an Autonomous System or an IGP instance. The PEs in a domain may reside within the same or in different Autonomous Systems, and a single Autonomous System may also encompass multiple domains.
2 つの PE が同じテナントに接続されており、それらの間で交換されるパケットに中継ルーターでの (テナント空間内の) データ パス IP ルックアップが必要ない場合、2 つの PE は同じドメインに属します。ゲートウェイ PE は複数の DOMAIN-ID を相互接続します。ドメイン境界は自律システムまたは IGP インスタンスに限定されません。ドメイン内の PE は、同じ自律システム内または異なる自律システム内に存在する場合があり、単一の自律システムに複数のドメインが含まれる場合もあります。
Example 1: Figure 4 depicts a scenario where Tenant Systems TS1 and TS2 belong to the same tenant, and they are located in different data centers that are connected by gateway PEs (see the "Gateway PE" definition below). These gateway PEs use IPVPN in the WAN. When TS1 sends traffic to TS2, the intermediate routers between PE1 and PE2 require a tenant IP lookup in their IP-VRFs so that the packets can be forwarded. In this example, there are three different domains. The gateway PEs connect the EVPN domains to the IPVPN domain.
例 1: 図 4 は、テナント システム TS1 と TS2 が同じテナントに属し、ゲートウェイ PE によって接続された異なるデータ センターに配置されているシナリオを示しています (以下の「ゲートウェイ PE」の定義を参照)。これらのゲートウェイ PE は WAN で IPVPN を使用します。TS1 がトラフィックを TS2 に送信する場合、PE1 と PE2 の間の中間ルータは、パケットを転送できるように、IP-VRF でのテナント IP ルックアップを必要とします。この例では、3 つの異なるドメインがあります。ゲートウェイ PE は、EVPN ドメインを IPVPN ドメインに接続します。
GW1------------GW3
+------+ +------+
+-------------|IP-VRF| |IP-VRF|-------------+
PE1 +------+ +------+ PE2
+------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | IPVPN | EVPN |IP-VRF|-TS2
+------+ GW2 GW4 +---+--+
| +------+ +------+ |
+-------------|IP-VRF| |IP-VRF|-------------+
+------+ +------+
+--------------+
DOMAIN 1 DOMAIN 2 DOMAIN 3
<---------------> <------------> <---------------->
Figure 4: Multiple Domain Data Center Interconnects (DCIs) Example
図 4: 複数ドメインのデータセンター相互接続 (DCI) の例
Example 2: Figure 5 illustrates a similar scenario, but PE1 and PE2 are now connected by a BGP Labeled Unicast (BGP-LU) tunnel, and they have a BGP peer relationship for EVPN. Contrary to Example 1, there is no need for tenant IP lookups on the intermediate routers in order to forward packets between PE1 and PE2. Therefore, there is only one domain in the network, and PE1/ PE2 belong to it.
例 2: 図 5 は同様のシナリオを示していますが、PE1 と PE2 は BGP ラベル付きユニキャスト (BGP-LU) トンネルによって接続されており、EVPN の BGP ピア関係を持っています。例 1 とは対照的に、PE1 と PE2 の間でパケットを転送するために中間ルーターでテナント IP ルックアップを行う必要はありません。したがって、ネットワーク内にはドメインが 1 つだけ存在し、PE1/PE2 が所属します。
EVPN
<------------------------------------------------->
BGP-LU
<------------------------------------------------->
ASBR------------ASBR
+------+ +------+
+-------------| | | |-------------+
PE1 +------+ +--+---+ PE2
+------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2
+------+ ASBR ASBR +---+--+
| +------+ +------+ |
+-------------| | | |-------------+
+------+ +------+
+--------------+
<--------------------DOMAIN-1--------------------->
Figure 5: Single Domain DCI Example
図 5: 単一ドメイン DCI の例
Ethernet Tag:
イーサネットタグ:
Used to represent a broadcast domain [RFC7432].
ブロードキャスト ドメインを表すために使用されます [RFC7432]。
EVI:
EVI:
An EVPN Instance spanning the PE devices participating in that EVPN [RFC7432].
その EVPN [RFC7432] に参加している PE デバイスにまたがる EVPN インスタンス。
Gateway PE:
ゲートウェイ PE:
An Interworking PE that connects two or more distinct domains, where each domain may be either a regular domain or a composite domain. A gateway PE may establish either Internal BGP (IBGP) [RFC4271] or External BGP (EBGP) [RFC4271] sessions with peers in the connected domains. Depending on its configuration, the gateway PE performs one of the following functions:
2 つ以上の異なるドメインを接続するインターワーキング PE。各ドメインは通常のドメインまたは複合ドメインのいずれかです。ゲートウェイ PE は、接続されたドメイン内のピアと内部 BGP (IBGP) [RFC4271] または外部 BGP (EBGP) [RFC4271] セッションを確立できます。ゲートウェイ PE は、その構成に応じて、次のいずれかの機能を実行します。
* Re-originates ISF routes using the same ISF SAFI between the connected domains.
* 接続されたドメイン間で同じ ISF SAFI を使用して ISF ルートを再発信します。
* Translates an ISF route received via one ISF SAFI and re-originates it into a domain that uses a different ISF SAFI.
* 1 つの ISF SAFI 経由で受信した ISF ルートを変換し、別の ISF SAFI を使用するドメインに再発信します。
A gateway PE follows the procedures defined in Section 8. A gateway PE interconnects multiple domains. If the gateway PE is configured to use D-PATH, each domain is identified by a DOMAIN-ID, and these DOMAIN-IDs are encoded in the D-PATH and included in ISF SAFI route advertisements. The structure and behavior of the D-PATH Path Attribute are described in Section 4.
ゲートウェイ PE は、セクション 8 で定義された手順に従います。ゲートウェイ PE は、複数のドメインを相互接続します。ゲートウェイ PE が D-PATH を使用するように構成されている場合、各ドメインは DOMAIN-ID によって識別され、これらの DOMAIN-ID は D-PATH でエンコードされ、ISF SAFI ルート アドバタイズメントに含まれます。D-PATH パス属性の構造と動作については、セクション 4 で説明します。
Example: Figure 6 illustrates a scenario where PE1 is a gateway PE since the EVPN and IPVPN SAFIs are enabled on different BGP peers, and a given local IP prefix IPn/x is sent to both BGP peers for the same tenant. PE2 and PE1 are in one domain, and PE3 and PE1 are in another domain.
例: 図 6 は、EVPN と IPVPN SAFI が異なる BGP ピアで有効になっており、特定のローカル IP プレフィックス IPn/x が同じテナントの両方の BGP ピアに送信されるため、PE1 がゲートウェイ PE であるシナリオを示しています。PE2 と PE1 は 1 つのドメインにあり、PE3 と PE1 は別のドメインにあります。
Interworking PE
+---+ EVPN +---+ IPVPN +---+
|PE2| <----> |PE1| <----> |PE3|
+---+ +---+ +---+
Gateway
Figure 6: Interworking Gateway PE Example
図 6: インターワーキング ゲートウェイ PE の例
Interworking PE:
インターワーキング PE:
A PE that is capable of advertising a given IP prefix using one or more of the following route types: an EVPN ISF route, either an EVPN MAC/IP Advertisement route or an EVPN IP Prefix route, and an IPVPN ISF route. An Interworking PE maintains a single IP-VRF per tenant and zero, one, or more MAC-VRFs per tenant. Each MAC-VRF may include one or more BTs, and each BT may be associated with the tenant's IP-VRF via an Integrated Routing and Bridging (IRB) interface. There are two types of Interworking PEs:
次のルート タイプの 1 つ以上を使用して、特定の IP プレフィックスをアドバタイズできる PE。EVPN ISF ルート、EVPN MAC/IP アドバタイズ ルートまたは EVPN IP プレフィックス ルート、および IPVPN ISF ルート。インターワーキング PE は、テナントごとに 1 つの IP-VRF と、テナントごとに 0、1、または複数の MAC-VRF を維持します。各 MAC-VRF には 1 つ以上の BT が含まれる場合があり、各 BT は Integrated Routing and Bridging (IRB) インターフェイスを介してテナントの IP-VRF に関連付けられる場合があります。インターワーキング PE には 2 つのタイプがあります。
* Composite PE
* 複合PE
* Gateway PE
* ゲートウェイPE
These two functions may be implemented independently on a per-tenant basis and may also coexist for the same tenant on a single PE.
これら 2 つの機能はテナントごとに独立して実装できますが、単一の PE 上の同じテナントに対して共存することもできます。
Example: Figure 1 shows an Interworking PE where ISF SAFIs are enabled. IP-VRF1 and MAC-VRF1 are instantiated on the PE and together provide ISF for the tenant.
例: 図 1 は、ISF SAFI が有効になっているインターワーキング PE を示しています。IP-VRF1 と MAC-VRF1 は PE 上でインスタンス化され、一緒にテナントに ISF を提供します。
IP-VRF:
IP-VRF:
An IP Virtual Routing and Forwarding table, as defined in [RFC4364] and [RFC9135]. Route Distinguisher and Route Target(s) are required properties of an IP-VRF. An IP-VRF is programmed with ISF routes.
[RFC4364] および [RFC9135] で定義されている IP 仮想ルーティングおよび転送テーブル。ルート識別子とルート ターゲットは、IP-VRF の必須プロパティです。IP-VRF は ISF ルートを使用してプログラムされています。
IRB:
IRB:
An Integrated Routing and Bridging interface [RFC9135]. It refers to the logical interface that connects a BT to an IP-VRF and allows the forwarding of packets with the destination in a different subnet.
統合されたルーティングおよびブリッジング インターフェイス [RFC9135]。これは、BT を IP-VRF に接続し、異なるサブネット内の宛先へのパケットの転送を可能にする論理インターフェイスを指します。
ISF route:
ISFルート:
An ISF route for a given prefix, whose ISF SAFI may change as it transits different domains. IPVPN routes as in [RFC4364] and [RFC4659], EVPN IP Prefix routes as in [RFC9136], or EVPN MAC/IP Advertisement routes when they are programmed within an IP-VRF [RFC9135] are considered ISF routes in this document.
特定のプレフィックスの ISF ルート。その ISF SAFI は、異なるドメインを通過するときに変更される可能性があります。[RFC4364] および [RFC4659] のような IPVPN ルート、[RFC9136] のような EVPN IP プレフィックス ルート、または IP-VRF [RFC9135] 内でプログラムされている場合の EVPN MAC/IP アドバタイズメント ルートは、このドキュメントでは ISF ルートとみなされます。
ISF SAFI:
ISF SAFI:
The ISF Subsequent Address Family Identifier defines a Multiprotocol BGP (MP-BGP) [RFC4760] Sub-Address Family used to advertise IP prefix reachability for ISF within a tenant network. The SAFIs used for ISF include 1 (applicable only to IPv4 and IPv6 AFIs), 128 (applicable only to IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI 25). The procedures defined in this document apply only to SAFI 128 and SAFI 70. Accordingly, for the purposes of this document, the term "ISF SAFI" refers exclusively to SAFI 128 or SAFI 70. The routes for these ISF SAFIs are referred to as IPVPN and EVPN routes. Note that the term "ISF SAFI" does not define a new SAFI; it is used solely as a collective reference to SAFI 128 and SAFI 70.
The ISF Subsequent Address Family Identifier defines a Multiprotocol BGP (MP-BGP) [RFC4760] Sub-Address Family used to advertise IP prefix reachability for ISF within a tenant network.The SAFIs used for ISF include 1 (applicable only to IPv4 and IPv6 AFIs), 128 (applicable only to IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI 25).The procedures defined in this document apply only to SAFI 128 and SAFI 70. Accordingly, for the purposes of this document, the term "ISF SAFI" refers exclusively to SAFI 128 or SAFI 70. The routes for these ISF SAFIs are referred to as IPVPN and EVPN routes.「ISF SAFI」という用語は新しい SAFI を定義するものではないことに注意してください。これは、SAFI 128 および SAFI 70 への集合的な参照としてのみ使用されます。
MAC-VRF:
MAC-VRF:
A MAC Virtual Routing and Forwarding table, as defined in [RFC7432]. A MAC-VRF represents the instantiation of an EVI on a PE. Each MAC-VRF is associated with a unique Route Distinguisher (RD) and one or more Route Targets (RTs), which are required attributes for its operation. These RD and RT values are typically distinct from those used by any associated IP-VRF, when such an IP-VRF is linked to the MAC-VRF through a BT via an IRB interface [RFC9135].
[RFC7432] で定義されている MAC 仮想ルーティングおよび転送テーブル。MAC-VRF は、PE 上の EVI のインスタンス化を表します。各 MAC-VRF は、その動作に必要な属性である一意のルート識別子（RD）および 1 つ以上のルート ターゲット（RT）に関連付けられています。これらの RD 値と RT 値は、通常、関連する IP-VRF が IRB インターフェイス [RFC9135] 経由で BT を介して MAC-VRF にリンクされている場合、その IP-VRF によって使用される値とは異なります。
MPLS/NVO/SRv6 tunnel:
MPLS/NVO/SRv6 トンネル:
A tunnel that may be based on Multiprotocol Label Switching (MPLS), a Network Virtualization Overlay (NVO) technology [RFC8365], or Segment Routing over IPv6 (SRv6) [RFC9252]. Such tunnels are utilized by both MAC-VRFs and IP-VRFs. Regardless of the underlying tunneling technology, the tunnel may carry either Ethernet or IP payloads. MAC-VRFs are restricted to using tunnels that carry Ethernet payloads -- such as Ethernet NVO tunnels [RFC9136] and SRv6 tunnels with Ethernet payload -- which are typically established via EVPN signaling. In contrast, IP-VRFs may utilize tunnels carrying Ethernet payloads (signaled via EVPN) or IP payloads (signaled via EVPN or IPVPN mechanisms). IPVPN-only PEs support IP-VRFs but do not support sending or receiving traffic over tunnels carrying Ethernet payloads.
マルチプロトコル ラベル スイッチング (MPLS)、ネットワーク仮想化オーバーレイ (NVO) テクノロジー [RFC8365]、または IPv6 上のセグメント ルーティング (SRv6) [RFC9252] に基づくトンネル。このようなトンネルは、MAC-VRF と IP-VRF の両方で利用されます。基礎となるトンネリング技術に関係なく、トンネルはイーサネットまたは IP ペイロードを伝送できます。MAC-VRF は、イーサネット ペイロードを伝送するトンネル（イーサネット NVO トンネル [RFC9136] やイーサネット ペイロードを備えた SRv6 トンネルなど） の使用に制限されており、通常は EVPN シグナリング経由で確立されます。対照的に、IP-VRF は、イーサネット ペイロード (EVPN 経由で通知される) または IP ペイロード (EVPN または IPVPN メカニズム経由で通知される) を伝送するトンネルを利用する場合があります。IPVPN 専用 PE は IP-VRF をサポートしますが、イーサネット ペイロードを伝送するトンネルを介したトラフィックの送受信はサポートしません。
Example: Figure 1 illustrates the use of an MPLS, NVO-based, or SRv6 tunnel to transport Ethernet frames associated with MAC-VRF1. The PE identifies the corresponding MAC-VRF and BT based on the EVPN label -- an MPLS label, a Virtual Network Identifier (VNI), or an SRv6 Segment ID -- depending on the encapsulation type. Additionally, Figure 1 shows two distinct MPLS/NVO/SRv6 tunnels used by IP-VRF1: one tunnel transports Ethernet frames, while the other carries IP packets. This demonstrates that IP-VRFs may concurrently utilize multiple tunnel types, depending on the payload and the signaling mechanism (EVPN or IPVPN).
例: 図 1 は、MPLS、NVO ベース、または SRv6 トンネルを使用して、MAC-VRF1 に関連付けられたイーサネット フレームを転送する方法を示しています。PE は、カプセル化タイプに応じて、EVPN ラベル（MPLS ラベル、仮想ネットワーク識別子（VNI）、または SRv6 セグメント ID）に基づいて、対応する MAC-VRF および BT を識別します。さらに、図 1 は、IP-VRF1 で使用される 2 つの異なる MPLS/NVO/SRv6 トンネルを示しています。1 つのトンネルはイーサネット フレームを転送し、もう 1 つのトンネルは IP パケットを伝送します。これは、ペイロードとシグナリング メカニズム（EVPN または IPVPN）に応じて、IP-VRF が複数のトンネル タイプを同時に利用できることを示しています。
NVE:
NVE:
A Network Virtualization Edge router [RFC8365].
ネットワーク仮想化エッジルーター [RFC8365]。
PE:
PE:
A Provider Edge device.
プロバイダー エッジ デバイス。
Regular Domain:
通常のドメイン:
A domain in which a single control plane ISF SAFI, i.e., IPVPN or EVPN, is used. A regular domain is composed of regular PEs; see the definition below. In Figures 4 and 5, all domains are regular domains.
単一のコントロール プレーン ISF SAFI、つまり IPVPN または EVPN が使用されるドメイン。通常のドメインは通常の PE で構成されます。以下の定義を参照してください。図 4 と 5 では、すべてのドメインが通常のドメインです。
Regular PE:
通常のPE:
A PE that is attached to a domain, either regular or composite, and that uses one of the control plane ISF SAFIs (IPVPN or EVPN) operating in the domain.
通常または複合のドメインに接続され、ドメイン内で動作するコントロール プレーン ISF SAFI (IPVPN または EVPN) の 1 つを使用する PE。
RT-2:
RT-2:
Route Type 2 or MAC/IP route, as per [RFC7432].
[RFC7432] によるルート タイプ 2 または MAC/IP ルート。
RT-5:
RT-5:
Route Type 5 or IP Prefix route, as per [RFC9136].
[RFC9136] によるルート タイプ 5 または IP プレフィックス ルート。
The BGP D-PATH Path Attribute is an optional and transitive BGP Path Attribute.
BGP D-PATH パス属性は、オプションの推移的な BGP パス属性です。
Similar to AS_PATH, D-PATH is composed of a sequence of domain segments. Each domain segment is composed of <domain segment length, domain segment value>, where the domain segment value is a sequence of one or more domains, as illustrated in Figure 7. Each domain is represented by <DOMAIN-ID:ISF_SAFI_TYPE>.
AS_PATH と同様に、D-PATH は一連のドメイン セグメントで構成されます。各ドメイン セグメントは、<ドメイン セグメント長、ドメイン セグメント値> で構成されます。図 7 に示すように、ドメイン セグメント値は 1 つ以上のドメインのシーケンスです。各ドメインは、<DOMAIN-ID:ISF_SAFI_TYPE> で表されます。
Octets
0 1 8 n
+---------------+----------------//--+----//-------------------+
|Domain Segment | Last Domain | Domain of Origin |
| Length | | |
+---------------+----------------//--+----//-------------------+
\__________________/
|
Octets v
0 6 7
+------------------//-----+----------------+
| DOMAIN-ID | ISF_SAFI_TYPE |
+------------------//-----+----------------+
\________________________/
|
Octets v
0 1 2 3 4 5 6
+-----------------------+-----------+
| Global | Local |
| Admin | Admin |
+-----------------------+-----------+
Figure 7: D-PATH Domain Segment
図 7: D-PATH ドメイン セグメント
Domain Segment Length:
ドメインセグメントの長さ:
A 1-octet length field. Contains the number of domains in the segment.
1 オクテットの長さのフィールド。セグメント内のドメインの数が含まれます。
Last Domain:
最後のドメイン:
Refers to the most recently added domain.
最近追加されたドメインを指します。
Domain of Origin:
原産地ドメイン:
Refers to the first domain added by the gateway PE that initialized the D-PATH for the ISF route. Multiple domains may exist between the Last Domain and the Domain of Origin.
ISF ルートの D-PATH を初期化したゲートウェイ PE によって追加された最初のドメインを指します。最後のドメインと元のドメインの間に複数のドメインが存在する場合があります。
DOMAIN-ID:
ドメインID:
A 6-octet field that represents a domain. It is composed of a 4-octet Global Administrator sub-field and a 2-octet Local Administrator sub-field. The Global Administrator sub-field MAY be filled with a public or private Autonomous System Number (ASN), an IPv4 address, or any value. The combined Global Administrator and Local Administrator can use any value that guarantees the uniqueness of the DOMAIN-ID (when the tenant network is connected to multiple Operators) and helps troubleshooting and debugging of D-PATH in ISF routes. A gateway PE that interconnects two domains is associated with two distinct DOMAIN-IDs, one per domain. All gateway PEs attached to the same domain MUST use the same DOMAIN-ID value to represent that domain. Expressing the Global Administrator and Local Administrator values as opaque unsigned integers in user interface and reporting (e.g., command-line interface (CLI) and YANG) is RECOMMENDED.
ドメインを表す 6 オクテットのフィールド。これは、4 オクテットの Global Administrator サブフィールドと 2 オクテットの Local Administrator サブフィールドで構成されます。Global Administrator サブフィールドには、パブリックまたはプライベートの自律システム番号 (ASN)、IPv4 アドレス、または任意の値を入力できます (MAY)。グローバル管理者とローカル管理者の組み合わせは、DOMAIN-ID の一意性を保証する任意の値を使用でき (テナント ネットワークが複数のオペレーターに接続されている場合)、ISF ルートの D-PATH のトラブルシューティングとデバッグに役立ちます。2 つのドメインを相互接続するゲートウェイ PE は、ドメインごとに 1 つずつ、2 つの異なる DOMAIN-ID に関連付けられます。同じドメインに接続されているすべてのゲートウェイ PE は、そのドメインを表すために同じ DOMAIN-ID 値を使用しなければなりません (MUST)。ユーザー インターフェイスとレポート (コマンドライン インターフェイス (CLI) や YANG など) では、グローバル管理者とローカル管理者の値を不透明な符号なし整数として表現することが推奨されます。
ISF_SAFI_TYPE:
ISF_SAFI_TYPE:
A 1-octet field that indicates the inter-subnet forwarding SAFI type in which a route was received by the gateway PE before the route is re-exported by the gateway PE into a different domain. The ISF_SAFI_TYPE field is informational and does not have any impact on the loop detection or BGP path selection procedures. Encoding the ISF_SAFI_TYPE provides operational benefits, as it allows operators to verify that the intended interworking is in place and that the route has traversed the expected domains using the intended ISF SAFIs in each domain. The non-zero ISF_SAFI_TYPE values come from the IANA "SAFI Values" registry [IANA-SAFI]. These are the values allowed by this document:
ルートがゲートウェイ PE によって別のドメインに再エクスポートされる前に、ルートがゲートウェイ PE によって受信されたサブネット間転送 SAFI タイプを示す 1 オクテットのフィールド。ISF_SAFI_TYPE フィールドは情報提供用であり、ループ検出または BGP パス選択手順には影響しません。ISF_SAFI_TYPE をエンコードすると、運用上の利点が得られます。これにより、オペレータは、意図したインターワーキングが確立されていること、および各ドメインの意図した ISF SAFI を使用してルートが予期されたドメインを通過したことを検証できるようになります。ゼロ以外の ISF_SAFI_TYPE 値は、IANA "SAFI Values" レジストリ [IANA-SAFI] から取得されます。この文書で許可されている値は次のとおりです。
+=======+==================================+
| Value | ISF_SAFI_TYPE |
+=======+==================================+
| 0 | Gateway PE local ISF route |
+-------+----------------------------------+
| 70 | EVPN (BGP EVPNs) |
+-------+----------------------------------+
| 128 | IPVPN (MPLS-labeled VPN address) |
+-------+----------------------------------+
Table 1
The BGP D-PATH Path Attribute is supported on ISF routes of types IPVPN and EVPN and MUST NOT be advertised along with routes different from IPVPN and EVPN routes. By default, the BGP D-PATH Path Attribute is not advertised and MUST be explicitly enabled by configuration on the gateway PEs. The rest of this section specifies procedures related to D-PATH:
BGP D-PATH パス属性は、タイプ IPVPN および EVPN の ISF ルートでサポートされており、IPVPN および EVPN ルートとは異なるルートと一緒にアドバタイズしてはなりません。デフォルトでは、BGP D-PATH パス属性はアドバタイズされず、ゲートウェイ PE の設定によって明示的に有効にする必要があります。このセクションの残りの部分では、D-PATH に関連する手順について説明します。
1. D-PATH identifies the sequence of domains, each identified by a <DOMAIN-ID:ISF_SAFI_TYPE> through which a given ISF route of type IPVPN or EVPN has passed.
1. D-PATH は一連のドメインを識別します。各ドメインは、タイプ IPVPN または EVPN の特定の ISF ルートが通過する <DOMAIN-ID:ISF_SAFI_TYPE> によって識別されます。
* This attribute list MAY contain one or more segments. Each segment's Domain Segment Length MUST be equal to or greater than one.
* この属性リストには 1 つ以上のセグメントを含めることができます (MAY)。各セグメントのドメイン セグメントの長さは 1 以上でなければなりません。
* The first entry in the list (leftmost) is the <DOMAIN-ID:ISF_SAFI_TYPE> from which a gateway PE is re-originating an ISF IPVPN or EVPN route. The last entry in the list (rightmost) is the <DOMAIN-ID:ISF_SAFI_TYPE> from which a gateway PE received an ISF IPVPN or EVPN route without a D-PATH Path Attribute (the Domain of Origin). Intermediate entries in the list are domains that the ISF IPVPN or EVPN route has transited.
* リストの最初のエントリ (左端) は、ゲートウェイ PE が ISF IPVPN または EVPN ルートを再発信する元の <DOMAIN-ID:ISF_SAFI_TYPE> です。リストの最後のエントリ (右端) は、ゲートウェイ PE が D-PATH パス属性 (起点ドメイン) のない ISF IPVPN または EVPN ルートを受信した <DOMAIN-ID:ISF_SAFI_TYPE> です。リストの中間エントリは、ISF IPVPN または EVPN ルートが通過したドメインです。
* As an example, an ISF IPVPN or EVPN route received with a D-PATH Path Attribute containing a domain segment of {length=2, <6500:2:IPVPN>,<6500:1:EVPN>} indicates that the route was originated in EVPN domain 6500:1 and re-originated into IPVPN domain 6500:2.
* たとえば、{length=2, <6500:2:IPVPN>,<6500:1:EVPN>} のドメイン セグメントを含む D-PATH パス属性で受信された ISF IPVPN または EVPN ルートは、ルートが EVPN ドメイン 6500:1 で発信され、IPVPN ドメイン 6500:2 に再発信されたことを示します。
* In order to minimize the number of segments in the D-PATH Path Attribute, the local gateway PE MUST prepend its own domain as the last element of the domain segment. If the act of prepending a new domain causes an overflow in the domain segment (i.e., more than 255 domains), the local gateway PE MUST prepend a new segment and prepend its own domain to this new segment.
* D-PATH パス属性内のセグメントの数を最小限に抑えるために、ローカル ゲートウェイ PE は、ドメイン セグメントの最後の要素として独自のドメインを先頭に追加しなければなりません (MUST)。新しいドメインを先頭に追加する行為により、ドメイン セグメント (つまり、255 を超えるドメイン) でオーバーフローが発生する場合、ローカル ゲートウェイ PE は、新しいセグメントを先頭に追加し、この新しいセグメントの先頭に独自のドメインを追加しなければなりません (MUST)。
2. D-PATH is added/modified by a gateway PE when re-originating an update to a different domain (which runs the same or different ISF SAFI), assuming the use of D-PATH is configured as follows:
2. D-PATH の使用が次のように設定されていると仮定すると、D-PATH は、別のドメイン (同じまたは異なる ISF SAFI を実行する) への更新を再発信するときに、ゲートウェイ PE によって追加/変更されます。
* The IP-VRF of a gateway PE that interconnects two domains is associated with two distinct DOMAIN-IDs, one per domain. These DOMAIN-IDs MUST be different. Each domain MUST be identified by a unique DOMAIN-ID. All gateway PEs attached to the same domain MUST use the same DOMAIN-ID value to represent that domain.
* 2 つのドメインを相互接続するゲートウェイ PE の IP-VRF は、ドメインごとに 1 つずつ、2 つの異なる DOMAIN-ID に関連付けられます。これらの DOMAIN-ID は異なっていなければなりません。各ドメインは一意の DOMAIN-ID で識別されなければなりません (MUST)。同じドメインに接続されているすべてのゲートウェイ PE は、そのドメインを表すために同じ DOMAIN-ID 値を使用しなければなりません (MUST)。
* Whenever a prefix arrives at a gateway PE in a particular ISF SAFI route, if the gateway PE needs to export that prefix to a BGP peer, the gateway PE MUST prepend a <DOMAIN-ID:ISF_SAFI_TYPE> to the list of domains in the D-PATH of the received route, as long as the gateway PE works in Uniform Propagation Mode (as explained in Section 5.2) and the use of D-PATH is configured as described at the beginning of this section.
* 特定の ISF SAFI ルートのゲートウェイ PE にプレフィックスが到着するたびに、ゲートウェイ PE がそのプレフィックスを BGP ピアにエクスポートする必要がある場合、ゲートウェイ PE が均一伝播モード (セクション 5.2 で説明) で動作し、D-PATH の使用が で説明されているように設定されている限り、ゲートウェイ PE は受信したルートの D-PATH 内のドメインのリストに <DOMAIN-ID:ISF_SAFI_TYPE> を付加しなければなりません (MUST)。このセクションの始まり。
* For instance, consider an IP-VRF configured with DOMAIN-IDs 6500:1 for EVPN and 6500:2 for IPVPN. If an EVPN route for prefix P is received and P is installed in the IP-VRF, then the corresponding IPVPN route for P, when exported to an IPVPN peer, will include the domain identifier <6500:1:EVPN> prepended to the existing D-PATH Path Attribute, assuming the use of D-PATH is configured, as described in the beginning of this section. Similarly, prefixes received in the IP-VRF from an IPVPN peer will be exported to EVPN peers with the domain identifier <6500:2:IPVPN> appended to the D-PATH Path Attribute, again assuming the use of D-PATH is configured.
* たとえば、EVPN の場合は DOMAIN-ID 6500:1、IPVPN の場合は 6500:2 で設定された IP-VRF について考えてみましょう。プレフィックス P の EVPN ルートが受信され、P が IP-VRF にインストールされている場合、P に対応する IPVPN ルートは、IPVPN ピアにエクスポートされるときに、このセクションの冒頭で説明したように D-PATH の使用が設定されていると仮定して、既存の D-PATH パス属性の先頭に付加されたドメイン識別子 <6500:1:EVPN> を含みます。同様に、IPVPN ピアから IP-VRF で受信したプレフィックスは、D-PATH の使用が設定されていることを前提として、D-PATH パス属性にドメイン識別子 <6500:2:IPVPN> が追加されて EVPN ピアにエクスポートされます。
* In the above example, if the EVPN route is received without D-PATH, the gateway PE will add the D-PATH Path Attribute with one segment {length=1, <6500:1:EVPN>} when re-advertising to domain 6500:2.
* 上記の例では、EVPN ルートが D-PATH なしで受信された場合、ゲートウェイ PE はドメイン 6500:2 に再アドバタイズするときに、1 つのセグメント {length=1, <6500:1:EVPN>} を持つ D-PATH パス属性を追加します。
* Within the Domain of Origin, the update does not contain a D-PATH Path Attribute because the update has not passed through a gateway PE yet.
* 発信元ドメイン内では、更新はまだゲートウェイ PE を通過していないため、更新には D-PATH パス属性が含まれません。
3. For a local ISF route, i.e., a configured static route or a route learned from a local Attachment Circuit, a gateway PE following this specification has three choices:
3. ローカル ISF ルート、つまり、設定されたスタティック ルート、またはローカル接続回線から学習したルートの場合、この仕様に従うゲートウェイ PE には 3 つの選択肢があります。
* The gateway PE advertises that ISF route without a D-PATH Path Attribute into one or more of its configured domains, in which case the D-PATH Path Attribute will be added by the other gateway PEs in each of those domains.
* ゲートウェイ PE は、D-PATH パス属性のない ISF ルートを、その構成済みドメインの 1 つ以上にアドバタイズします。この場合、D-PATH パス属性は、それらの各ドメイン内の他のゲートウェイ PE によって追加されます。
* The gateway PE advertises that ISF route with a D-PATH Path Attribute into one or more of its configured domains (assuming the use of D-PATH is configured), in which case the D-PATH Path Attribute in each copy of the ISF route is initialized with an ISF_SAFI_TYPE of 0 and the DOMAIN-ID of the domain with which the ISF route is associated.
* ゲートウェイ PE は、D-PATH パス属性を持つ ISF ルートを、その構成済みドメインの 1 つ以上にアドバタイズします (D-PATH の使用が構成されていると仮定します)。この場合、ISF ルートの各コピーの D-PATH パス属性は、ISF_SAFI_TYPE 0 および ISF ルートが関連付けられているドメインの DOMAIN-ID で初期化されます。
* The gateway PE advertises the ISF route with a D-PATH Path Attribute (assuming the use of D-PATH is configured) containing a locally configured domain identifier associated with its local ISF routes into one or more of its configured domains. In this case, the D-PATH Path Attribute in each copy of the ISF route is initialized with an ISF_SAFI_TYPE value of 0 and the DOMAIN-ID representing the local ISF domain. The DOMAIN-ID MUST be globally unique and MAY be shared across multiple gateway PEs.
* ゲートウェイ PE は、ローカル ISF ルートに関連付けられたローカルに設定されたドメイン識別子を含む D-PATH パス属性 (D-PATH の使用が設定されていると仮定) を使用して ISF ルートを 1 つ以上の設定済みドメインにアドバタイズします。この場合、ISF ルートの各コピーの D-PATH パス属性は、ISF_SAFI_TYPE 値 0 とローカル ISF ドメインを表す DOMAIN-ID で初期化されます。DOMAIN-ID はグローバルに一意である必要があり、複数のゲートウェイ PE 間で共有できます。
Although all three options provide mechanisms for detecting control plane loops, this third option is RECOMMENDED, as it conveys additional information about the origin of the route. Specifically, it allows the receiving PE to identify the route as having originated from a local gateway based on the combination of the DOMAIN-ID and the ISF_SAFI_TYPE value.
3 つのオプションはすべてコントロール プレーン ループを検出するためのメカニズムを提供しますが、ルートの起点に関する追加情報を伝えるため、この 3 番目のオプションが推奨されます。具体的には、受信側 PE が、DOMAIN-ID と ISF_SAFI_TYPE 値の組み合わせに基づいて、ルートがローカル ゲートウェイから発信されたものであることを識別できるようになります。
4. An ISF route of type IPVPN or EVPN received by a gateway PE that includes a D-PATH Path Attribute containing one or more DOMAIN-ID values locally associated with the corresponding IP-VRF MUST be considered a looped ISF route for the purposes of re-advertisement into adjacent domains. In such cases:
4. 対応する IP-VRF にローカルに関連付けられた 1 つ以上の DOMAIN-ID 値を含む D-PATH パス属性を含む、ゲートウェイ PE によって受信されたタイプ IPVPN または EVPN の ISF ルートは、隣接ドメインへの再アドバタイズを目的として、ループされた ISF ルートと見なされなければなりません (MUST)。そのような場合:
* The ISF route MUST be flagged as "looped".
* ISF ルートには「ループ」というフラグが付けられなければなりません。
* The route MUST NOT be re-exported to any other domain.
* ルートを他のドメインに再エクスポートしてはなりません。
* The route is installed in the IP-VRF only if it is selected as the best path according to the procedures defined in Section 6.
* ルートは、セクション 6 で定義された手順に従って最適なパスとして選択された場合にのみ、IP-VRF にインストールされます。
For the purpose of loop detection, the ISF_SAFI_TYPE value associated with a DOMAIN-ID in the D-PATH Path Attribute is irrelevant. That is, a route is considered looped if it contains at least one DOMAIN-ID that matches any local DOMAIN-ID configured on the gateway PE, regardless of the ISF_SAFI_TYPE value.
ループ検出の目的では、D-PATH パス属性の DOMAIN-ID に関連付けられた ISF_SAFI_TYPE 値は無関係です。つまり、ISF_SAFI_TYPE 値に関係なく、ゲートウェイ PE に設定されているローカル DOMAIN-ID と一致する DOMAIN-ID がルートに少なくとも 1 つ含まれている場合、そのルートはループしていると見なされます。
Example: In the scenario illustrated in Figure 4, gateway GW1 receives two ISF routes for the same prefix associated with TS1:
例: 図 4 に示すシナリオでは、ゲートウェイ GW1 は、TS1 に関連付けられた同じプレフィックスの 2 つの ISF ルートを受信します。
* An EVPN IP Prefix route with a next hop of PE1 and no D-PATH Path Attribute.
* ネクスト ホップが PE1 で、D-PATH パス属性がない EVPN IP プレフィックス ルート。
* An IPVPN route with a next hop of GW2 and a D-PATH Path Attribute containing a single segment: {length=1, <6500:1:EVPN>}, where 6500:1 is assumed to be the DOMAIN-ID for domain 1, which is local to GW1.
* GW2 のネクスト ホップと、単一セグメントを含む D-PATH パス属性を持つ IPVPN ルート: {length=1, <6500:1:EVPN>}。ここで、6500:1 は、GW1 に対してローカルであるドメイン 1 の DOMAIN-ID であると想定されます。
Upon receiving the IPVPN route, GW1 identifies 6500:1 as a locally configured DOMAIN-ID and therefore flags the route as "looped". As a result, GW1 does not install this route in the tenant IP-VRF because the route selection process prefers the EVPN IP Prefix route (due to its shorter D-PATH Path Attribute, as specified in Section 6). Loop detection is applied even if the ISF_SAFI_TYPE value in the D-PATH Path Attribute is unknown to GW1 or does not match any SAFI defined in this specification.
IPVPN ルートを受信すると、GW1 はローカルに設定された DOMAIN-ID として 6500:1 を識別し、そのルートに「ループ」のフラグを立てます。その結果、ルート選択プロセスでは EVPN IP プレフィックス ルートが優先されるため、GW1 はこのルートをテナント IP-VRF にインストールしません (セクション 6 で指定されているように、D-PATH パス属性が短いため)。ループ検出は、D-PATH パス属性の ISF_SAFI_TYPE 値が GW1 にとって不明な場合、またはこの仕様で定義されている SAFI と一致しない場合でも適用されます。
5. A DOMAIN-ID configured on a gateway PE MAY be either assigned at the domain interconnection level or scoped individually per tenant IP-VRF.
5. ゲートウェイ PE 上に設定された DOMAIN-ID は、ドメイン相互接続レベルで割り当てられるか、テナント IP-VRF ごとに個別にスコープ設定される可能性があります。
* When the DOMAIN-ID is allocated at the peering domain level, it SHALL apply to all tenant IP-VRFs associated with that domain.
* DOMAIN-ID がピアリング ドメイン レベルで割り当てられる場合、そのドメインに関連付けられたすべてのテナント IP-VRF に適用されるものとします (SHALL)。
* When the DOMAIN-ID is allocated for a specific tenant IP-VRF, the processing of received D-PATH Path Attributes and their subsequent propagation SHALL be performed in the context of that IP-VRF's DOMAIN-ID.
* DOMAIN-ID が特定のテナント IP-VRF に割り当てられる場合、受信した D-PATH パス属性の処理とその後の伝播は、その IP-VRF の DOMAIN-ID のコンテキストで実行されるものとします (SHALL)。
A per-tenant IP-VRF DOMAIN-ID assignment is particularly useful in scenarios involving route leaking. For example, consider two gateway PEs, PE1 and PE2, both associated with different tenant IP-VRFs and denoted as IP-VRF-1 and IP-VRF-2, respectively. If PE1 advertises ISF SAFI routes for IP-VRF-1 with a DOMAIN-ID of 6500:1, and these routes are received on PE2 and subsequently leaked from IP-VRF-1 into IP-VRF-2, the re-advertisement of the routes from PE2 back to PE1 in the context of IP-VRF-2 will not be considered looped by PE1. This is because PE1 processes the route in the context of IP-VRF-2, for which DOMAIN-ID 6500:1 is not locally configured.
テナントごとの IP-VRF DOMAIN-ID の割り当ては、ルート リークが関係するシナリオで特に役立ちます。たとえば、2 つのゲートウェイ PE PE1 と PE2 があり、どちらも異なるテナント IP-VRF に関連付けられており、それぞれ IP-VRF-1 と IP-VRF-2 として示されているとします。PE1 が DOMAIN-ID 6500:1 の IP-VRF-1 の ISF SAFI ルートをアドバタイズし、これらのルートが PE2 で受信され、その後 IP-VRF-1 から IP-VRF-2 に漏洩した場合、IP-VRF-2 のコンテキストで PE2 から PE1 に戻るルートの再アドバタイズは PE1 によってループされているとは見なされません。これは、PE1 が IP-VRF-2 のコンテキストでルートを処理し、DOMAIN-ID 6500:1 がローカルに設定されていないためです。
6. The number of domains encoded in the D-PATH Path Attribute reflects the number of gateway PEs that the corresponding ISF route update has traversed. If a transit gateway PE performs route leaking between two local tenant IP-VRFs, it MAY prepend a domain to the D-PATH Path Attribute with an ISF_SAFI_TYPE value of 0 when exporting the leaked route into an ISF SAFI. In such cases, the total number of domain entries in the D-PATH Path Attribute reflects not only the number of gateway PEs through which the ISF route has been re-originated but also the number of tenant IP-VRF instances across those gateway PEs.
6. D-PATH パス属性でエンコードされたドメインの数は、対応する ISF ルート更新が通過したゲートウェイ PE の数を反映します。トランジット ゲートウェイ PE が 2 つのローカル テナント IP-VRF 間でルート リークを実行する場合、リークしたルートを ISF SAFI にエクスポートするときに、ISF_SAFI_TYPE 値が 0 のドメインを D-PATH パス属性の先頭に追加してもよい(MAY)。このような場合、D-PATH パス属性のドメイン エントリの総数は、ISF ルートが再生成されるゲートウェイ PE の数だけでなく、それらのゲートウェイ PE にわたるテナント IP-VRF インスタンスの数も反映します。
7. The following error-handling procedures apply to the D-PATH Path Attribute:
7. 次のエラー処理手順は、D-PATH パス属性に適用されます。
* A received D-PATH Path Attribute MUST be considered malformed if it contains a malformed domain segment or if the total length of the D-PATH Path Attribute is less than 8 octets.
* 受信した D-PATH パス属性は、不正な形式のドメイン セグメントが含まれている場合、または D-PATH パス属性の全長が 8 オクテット未満である場合、不正な形式であるとみなされなければなりません (MUST)。
* A domain segment MUST be considered malformed under any of the following conditions:
* ドメイン セグメントは、次のいずれかの条件下では不正な形式であると見なされなければなりません。
- The length of the domain segment is zero.
- ドメインセグメントの長さはゼロです。
- The length of the domain segment exceeds the remaining length of the enclosing D-PATH Path Attribute.
- ドメイン セグメントの長さが、それを囲む D-PATH パス属性の残りの長さを超えています。
- Less than 8 octets remain after the last successfully parsed domain segment.
- 最後に正常に解析されたドメイン セグメントの後に残るのは 8 オクテット未満です。
- Each domain segment consists of a 1-octet length field indicating the number of domains in the segment, with each domain encoded in 7 octets. If the total length of the domain segment (i.e., 1 + 7 x number of domains) exceeds the remaining length of the D-PATH Path Attribute, the domain segment is considered malformed.
- 各ドメイン セグメントは、セグメント内のドメインの数を示す 1 オクテットの長さのフィールドで構成され、各ドメインは 7 オクテットでエンコードされます。ドメイン セグメントの合計長 (つまり、1 + 7 x ドメイン数) が D-PATH パス属性の残りの長さを超える場合、ドメイン セグメントは不正な形式であるとみなされます。
* A BGP speaker receiving an UPDATE message containing a malformed D-PATH Path Attribute SHALL apply the "treat-as-withdraw" procedure, as specified in [RFC7606].
* 不正な形式の D-PATH パス属性を含む UPDATE メッセージを受信した BGP スピーカは、[RFC7606] で規定されている「treat-as-withdraw」手順を適用するものとします (SHALL)。
* Domains within the D-PATH Path Attribute that contain unrecognized ISF_SAFI_TYPE values MAY be accepted and MUST NOT be considered an error.
* 認識できない ISF_SAFI_TYPE 値を含む D-PATH パス属性内のドメインは受け入れられてもよく (MAY)、エラーとみなされてはならない (MUST NOT)。
* The D-PATH Path Attribute MUST NOT appear more than once in the Path Attributes of a given BGP UPDATE message. If multiple instances of the D-PATH Path Attribute are present, all instances other than the first MUST be discarded, and the UPDATE message MUST continue to be processed. This behavior follows [RFC7606], including the associated logging considerations.
* D-PATH パス属性は、特定の BGP UPDATE メッセージのパス属性に複数回出現してはなりません。D-PATH パス属性のインスタンスが複数存在する場合、最初のインスタンス以外のすべてのインスタンスは破棄されなければならず (MUST)、UPDATE メッセージは処理を継続しなければなりません (MUST)。この動作は、関連するロギングに関する考慮事項も含め、[RFC7606] に従います。
* The D-PATH Path Attribute MAY be included only in UPDATE messages that carry IPVPN or EVPN routes. It MUST NOT be included with any other AFI/SAFI combinations. If a D-PATH Path Attribute is received in an UPDATE message associated with an unsupported AFI/SAFI, the "treat-as-withdraw" procedure MUST be applied in accordance with [RFC7606].
* D-PATH パス属性は、IPVPN または EVPN ルートを伝送する UPDATE メッセージにのみ含めることができます (MAY)。他の AFI/SAFI の組み合わせに含めてはなりません。サポートされていない AFI/SAFI に関連付けられた UPDATE メッセージで D-PATH パス属性を受信した場合、[RFC7606] に従って "treat-as-withdraw" 手順を適用しなければなりません (MUST)。
A gateway PE, depending on its local configuration, is required to re-originate an ISF route between two domains that utilize either the same or different ISF SAFIs. This requires defining how a gateway PE handles the BGP Path Attributes associated with the ISF route during such re-origination.
ゲートウェイ PE は、そのローカル設定に応じて、同じまたは異なる ISF SAFI を利用する 2 つのドメイン間で ISF ルートを再発信する必要があります。これには、そのような再発信中に ISF ルートに関連付けられた BGP パス属性をゲートウェイ PE が処理する方法を定義する必要があります。
This section specifies the BGP Path Attribute propagation behaviors that a gateway PE MAY apply when it receives an ISF route with ISF SAFI x, installs the route into the relevant IP-VRF, and subsequently re-advertises the route as an ISF route using ISF SAFI y. The values of ISF SAFI x and SAFI y MAY be the same or different.
このセクションでは、ゲートウェイ PE が ISF SAFI x で ISF ルートを受信し、そのルートを関連する IP-VRF にインストールし、その後 ISF SAFI y を使用してルートを ISF ルートとして再アドバタイズするときに適用できる BGP パス属性伝播動作を指定します。ISF SAFI x と SAFI y の値は同じでも異なっていてもよい(MAY)。
The No Propagation Mode is the default operational mode for Gateway PEs when re-exporting ISF routes from one domain into another. In this mode, the gateway PE re-initializes the BGP Path Attributes during the re-origination of an ISF route, treating it in the same manner as a directly connected or locally originated IP prefix.
伝播なしモードは、ISF ルートをあるドメインから別のドメインに再エクスポートする場合のゲートウェイ PE のデフォルトの動作モードです。このモードでは、ゲートウェイ PE は、ISF ルートの再発信中に BGP パス属性を再初期化し、直接接続された、またはローカルに発信された IP プレフィックスと同じように扱います。
This mode is suitable for deployment scenarios where the source domain -- for example, an EVPN domain -- is "abstracted" and treated as a virtual Customer Edge (CE) and where remote IPVPN or IP-based PEs do not rely on the BGP Path Attributes of the source EVPN domain for best-path selection or the application of routing policy.
このモードは、ソース ドメイン (EVPN ドメインなど) が「抽象化」され、仮想カスタマー エッジ (CE) として扱われ、リモート IPVPN または IP ベースの PE がベスト パスの選択やルーティング ポリシーの適用においてソース EVPN ドメインの BGP パス属性に依存しない展開シナリオに適しています。
It is important to note that, in No Propagation Mode, the D-PATH Path Attribute is not propagated. As a result, redundant gateway PEs may be susceptible to routing loops. While such loops may be mitigated using routing policies or additional attributes, such as the Route Origin extended community [RFC4360], this approach does not guarantee detection or prevention of all potential loop scenarios.
伝播なしモードでは、D-PATH パス属性は伝播されないことに注意することが重要です。その結果、冗長ゲートウェイ PE はルーティング ループの影響を受ける可能性があります。このようなループは、ルーティング ポリシーや Route Origin 拡張コミュニティ [RFC4360] などの追加属性を使用して軽減できますが、このアプローチはすべての潜在的なループ シナリオの検出または防止を保証するものではありません。
In Uniform Propagation Mode, the gateway PE retains and copies a consistent set of commonly used BGP Path Attributes when re-originating an ISF route between domains. This mode is typically employed in deployments where IP prefixes are seamlessly distributed using EVPN and/or IPVPN SAFIs. This specification permits the propagation of a limited set of commonly used attributes, while discouraging indiscriminate copying and re-advertisement, primarily for security reasons.
均一伝播モードでは、ゲートウェイ PE は、ドメイン間で ISF ルートを再発信するときに、一般的に使用される BGP パス属性の一貫したセットを保持およびコピーします。このモードは通常、EVPN や IPVPN SAFI を使用して IP プレフィックスがシームレスに配布される展開で使用されます。この仕様は、主にセキュリティ上の理由から、無差別なコピーや再宣伝を阻止しながら、一般的に使用される限られた属性セットの伝播を許可します。
The following normative behavior MUST be followed by a gateway PE operating in Uniform Propagation Mode:
均一伝播モードで動作するゲートウェイ PE は、次の規範的な動作に従う必要があります。
1. Upon receiving an ISF route, and provided that no validation errors are detected and the route is permitted by local policy, the gateway PE imports the route into the associated IP-VRF and retains the original BGP Path Attributes. When re-advertising the route into a different domain, the gateway PE SHOULD, by default, propagate only the following set of attributes. All other Path Attributes SHOULD NOT be propagated unless explicitly permitted by local import/export policies:
1. ISF ルートを受信すると、検証エラーが検出されず、ルートがローカル ポリシーによって許可されている場合、ゲートウェイ PE はルートを関連する IP-VRF にインポートし、元の BGP パス属性を保持します。ルートを別のドメインに再アドバタイズする場合、ゲートウェイ PE は、デフォルトで、次の属性セットのみを伝播する必要があります (SHOULD)。他のすべてのパス属性は、ローカルのインポート/エクスポート ポリシーで明示的に許可されていない限り、伝播すべきではありません。
* AS_PATH
* AS_パス
* D-PATH (only when advertising IPVPN or EVPN routes)
* D-PATH (IPVPN または EVPN ルートをアドバタイズする場合のみ)
* IBGP-only attributes (when advertising to IBGP peers): LOCAL_PREF, ORIGINATOR_ID, and CLUSTER_ID
* IBGP のみの属性 (IBGP ピアにアドバタイズする場合): LOCAL_PREF、ORIGINATOR_ID、および CLUSTER_ID
* MULTI_EXIT_DISC (MED)
* MULTI_EXIT_DISC (MED)
* Accumulated IGP (AIGP) [RFC7311]
* 累積IGP (AIGP) [RFC7311]
* COMMUNITY, EXTENDED_COMMUNITY, and LARGE_COMMUNITY, except where explicitly excluded in Item 4 below.
* COMMUNITY、EXTENDED_COMMUNITY、および LARGE_COMMUNITY。ただし、以下の項目 4 で明示的に除外される場合を除きます。
2. When re-advertising an ISF route to an IBGP peer, the gateway PE SHOULD preserve the AS_PATH of the original ISF route without modification. When re-advertising to an EBGP peer, the gateway PE SHOULD prepend the IP-VRF's ASN to the preserved AS_PATH.
2. ISF ルートを IBGP ピアに再アドバタイズする場合、ゲートウェイ PE は元の ISF ルートの AS_PATH を変更せずに保存する必要があります (SHOULD)。EBGP ピアに再アドバタイズする場合、ゲートウェイ PE は、保存されている AS_PATH の先頭に IP-VRF の ASN を追加する必要があります (SHOULD)。
3. When re-originating an ISF route to IBGP peers, the gateway PE SHOULD retain IBGP-only attributes (e.g., LOCAL_PREF, ORIGINATOR_ID, and CLUSTER_ID) from the original ISF route. As the route is re-originated, the gateway PE is not required to perform the RR function described in [RFC4456].
3. ISF ルートを IBGP ピアに再発信する場合、ゲートウェイ PE は元の ISF ルートからの IBGP のみの属性 (LOCAL_PREF、ORIGINATOR_ID、および CLUSTER_ID など) を保持すべきです (SHOULD)。ルートが再生成されるため、ゲートウェイ PE は [RFC4456] で説明されている RR 機能を実行する必要がありません。
4. As stated in Item 1, the gateway PE SHOULD preserve the COMMUNITY, EXTENDED_COMMUNITY, and LARGE_COMMUNITY attributes from the original ISF route. However, the following exceptions apply:
4. 項目 1 で述べたように、ゲートウェイ PE は、元の ISF ルートの COMMUNITY、EXTENDED_COMMUNITY、および LARGE_COMMUNITY 属性を保存すべきです (SHOULD)。ただし、次の例外が適用されます。
a. BGP Encapsulation Extended Communities, as defined in [RFC9012], SHOULD NOT be propagated.
a. [RFC9012] で定義されている BGP カプセル化拡張コミュニティは、伝播すべきではありません (SHOULD NOT)。
b. Route Target Extended Communities SHOULD NOT be propagated and SHOULD be re-initialized when re-advertising the ISF route into a different domain. The re-initialized Route Target value MAY match the value used in the original route.
b. ルート ターゲット拡張コミュニティは伝播されるべきではなく、ISF ルートを別のドメインに再アドバタイズするときに再初期化されるべきです。再初期化された Route Target 値は、元のルートで使用されている値と一致してもよい (MAY)。
c. All EVPN-specific Extended Communities SHOULD NOT be propagated.
c. すべての EVPN 固有の拡張コミュニティを伝播すべきではありません。
d. Gateway PEs SHOULD support import/export policies capable of matching COMMUNITY, EXTENDED_COMMUNITY, and LARGE_COMMUNITY values to permit or deny their propagation between domains when the default propagation behavior needs to be overridden.
d. ゲートウェイ PE は、デフォルトの伝播動作をオーバーライドする必要がある場合に、ドメイン間の伝播を許可または拒否するために、COMMUNITY、EXTENDED_COMMUNITY、および LARGE_COMMUNITY の値を照合できるインポート/エクスポート ポリシーをサポートする必要があります (SHOULD)。
The gateway PE SHOULD NOT copy the above Extended Community types in "a", "b", and "c" from the original ISF route into the re-advertised ISF route. Certain Extended Communities may influence how the receiving PE processes the route. Propagating such attributes into another domain could therefore lead to unintended behavior. For example, if the BGP Encapsulation Extended Community is propagated into a destination domain that uses a different encapsulation, a receiving PE in that domain might interpret the label field of the EVPN ISF route according to an encapsulation context that does not apply locally [RFC8365]. This could result in the route being discarded or programmed with incorrect encapsulation parameters.
ゲートウェイ PE は、「a」、「b」、および「c」の上記の拡張コミュニティ タイプを元の ISF ルートから再アドバタイズされた ISF ルートにコピーしてはなりません (SHOULD NOT)。特定の拡張コミュニティは、受信側 PE がルートを処理する方法に影響を与える可能性があります。したがって、そのような属性を別のドメインに伝播すると、意図しない動作が発生する可能性があります。たとえば、BGP カプセル化拡張コミュニティが、別のカプセル化を使用する宛先ドメインに伝播される場合、そのドメインの受信 PE は、ローカルに適用されないカプセル化コンテキスト [RFC8365] に従って EVPN ISF ルートのラベル フィールドを解釈する可能性があります。これにより、ルートが破棄されたり、誤ったカプセル化パラメータがプログラムされたりする可能性があります。
5. For a given ISF route, only the BGP Path Attributes associated with the best path MAY be propagated when re-advertising the route into a different domain. If multiple paths are received for the same prefix within the same ISF SAFI, the standard BGP best-path selection procedure MUST be applied to determine the active path and its associated attributes. Even when Equal-Cost Multipath (ECMP) is enabled for the IP-VRF, only the Path Attributes of the selected best path SHOULD be propagated.
5. 特定の ISF ルートについては、そのルートを別のドメインに再アドバタイズするときに、最適パスに関連付けられた BGP パス属性のみを伝播してもよい(MAY)。同じ ISF SAFI 内の同じプレフィックスに対して複数のパスを受信した場合、標準の BGP 最良パス選択手順を適用して、アクティブ パスとその関連属性を決定する必要があります。IP-VRF に対して等コスト マルチパス（ECMP）が有効になっている場合でも、選択された最適パスのパス属性のみが伝播されるべきです（SHOULD）。
Instead of re-originating a high number of (host) ISF routes between domains, a gateway PE that receives multiple ISF routes from a domain MAY choose to re-originate a single ISF aggregate route into a different domain. In this document, aggregation is used to combine the characteristics of multiple ISF routes in such a way that a single aggregate ISF route can be re-originated to the destination domain. Aggregation of multiple ISF routes of one ISF SAFI into an aggregate ISF route is only done by a gateway PE.
ドメイン間で多数の (ホスト) ISF ルートを再発信する代わりに、ドメインから複数の ISF ルートを受信するゲートウェイ PE は、単一の ISF 集約ルートを別のドメインに再発信することを選択してもよい(MAY)。このドキュメントでは、単一の集約 ISF ルートを宛先ドメインに再発信できるように、集約を使用して複数の ISF ルートの特性を組み合わせます。1 つの ISF SAFI の複数の ISF ルートを集約 ISF ルートに集約することは、ゲートウェイ PE によってのみ行われます。
Aggregation on gateway PEs may use either the No Propagation Mode or the Uniform Propagation Mode explained in Sections 5.1 and 5.2, respectively.
ゲートウェイ PE での集約では、それぞれセクション 5.1 と 5.2 で説明されている非伝播モードまたは均一伝播モードのいずれかを使用できます。
When using Uniform Propagation Mode, Path Attributes of the same type code MAY be aggregated according to the following rules:
均一伝播モードを使用する場合、同じタイプ コードのパス属性は、次の規則に従って集約されてもよい (MAY)。
* AS_PATH is aggregated based on the rules in [RFC4271]. The gateway PEs are not expected to receive AS_PATH attributes with path segments of type AS_SET [RFC9774]. Routes received with AS_PATH attributes including AS_SET path segments MUST NOT be aggregated.
* AS_PATH は [RFC4271] の規則に基づいて集約されます。ゲートウェイ PE は、タイプ AS_SET [RFC9774] のパス セグメントを持つ AS_PATH 属性を受け取ることは期待されていません。AS_SET パス セグメントを含む AS_PATH 属性で受信したルートは集約してはなりません (MUST NOT)。
* An ISF aggregate route SHOULD NOT be advertised unless all the contributing ISF routes have the same D-PATH DOMAIN-ID members, regardless of their order. If there is at least one contributing ISF route that has a different D-PATH DOMAIN-ID, the gateway PE SHOULD advertise each contributing ISF route with its own D-PATH (prepended with the gateway's domain). An implementation MAY, by local policy, override this behavior and advertise an ISF aggregate route without the D-PATH Path Attribute when the contributing routes do not share identical D-PATH DOMAIN-ID members. In such cases, redundant gateway PEs SHOULD apply a consistent policy to prevent the advertisement of aggregate routes with inconsistent D-PATH usage into the destination domain.
* ISF 集約ルートは、順序に関係なく、寄与するすべての ISF ルートが同じ D-PATH DOMAIN-ID メンバーを持たない限り、アドバタイズしてはなりません (SHOULD NOT)。異なる D-PATH DOMAIN-ID を持つ寄与 ISF ルートが少なくとも 1 つある場合、ゲートウェイ PE は、寄与する各 ISF ルートを独自の D-PATH (ゲートウェイのドメインが先頭に付加された) でアドバタイズする必要があります (SHOULD)。実装は、ローカル ポリシーによって、寄与するルートが同一の D-PATH DOMAIN-ID メンバーを共有しない場合、この動作をオーバーライドし、D-PATH パス属性なしで ISF 集約ルートをアドバタイズしてもよい(MAY)。このような場合、冗長ゲートウェイ PE は、一貫性のないポリシーを適用して、一貫性のない D-PATH 使用法を持つ集約ルートが宛先ドメインにアドバタイズされるのを防ぐ必要があります (SHOULD)。
* The Community, Extended Community, and Large Community attributes of an aggregated ISF route SHOULD include the union of the corresponding attributes from all constituent ISF routes that were aggregated, with the exception of those Extended Community types explicitly excluded from propagation as specified in Section 5.2 or those for which the applicable specifications define different handling.
* 集約された ISF ルートのコミュニティ、拡張コミュニティ、および大規模コミュニティ属性には、セクション 5.2 で指定されている伝播から明示的に除外された拡張コミュニティ タイプ、または適用される仕様で異なる処理が定義されているタイプを除き、集約されたすべての構成 ISF ルートからの対応する属性の結合が含まれる必要があります (SHOULD)。
* For other attributes, the rules described in [RFC4271] or the attribute-applicable specifications are followed.
* その他の属性については、[RFC4271] に記述されている規則、または属性に適用される仕様に従います。
If the conditions for route aggregation, as specified above, are satisfied, operators SHOULD consider enabling aggregation in environments with large-scale tenant networks where a significant number of host routes are present. This practice is particularly applicable to deployments such as large-scale data centers.
上記で指定されたルート集約の条件が満たされる場合、事業者は、多数のホスト ルートが存在する大規模なテナント ネットワークの環境で集約を有効にすることを検討すべきです(SHOULD)。この実践は、大規模なデータセンターなどの展開に特に当てはまります。
A PE router may receive the same IP prefix via ISF routes with different ISF SAFIs and from either the same or different BGP peers. Additionally, the same IP prefix (e.g., a host route) may be received in both an EVPN MAC/IP Advertisement route and an EVPN IP Prefix route. To ensure consistent and deterministic forwarding behavior, a route selection procedure across all ISF SAFIs is required.
PE ルーターは、異なる ISF SAFI を持つ ISF ルートを介して、同じまたは異なる BGP ピアから同じ IP プレフィックスを受信する場合があります。さらに、同じ IP プレフィックス (ホスト ルートなど) が、EVPN MAC/IP 広告ルートと EVPN IP プレフィックス ルートの両方で受信される場合があります。一貫性のある決定的な転送動作を保証するには、すべての ISF SAFI にわたるルート選択手順が必要です。
The objectives of this route selection process are as follows:
このルート選択プロセスの目的は次のとおりです。
* To ensure that all composite and gateway PEs have a consistent and deterministic view of the preferred path to reach a given IP prefix.
* すべてのコンポジット PE とゲートウェイ PE が、特定の IP プレフィックスに到達するための優先パスの一貫した決定的なビューを確保できるようにするため。
* To enable meaningful comparison of routes advertised in EVPN and non-EVPN ISF SAFIs based on commonly used path attributes.
* 一般的に使用されるパス属性に基づいて、EVPN と非 EVPN ISF SAFI でアドバタイズされたルートを有意義に比較できるようにします。
* To support ECMP forwarding across EVPN and non-EVPN ISF SAFI routes, where applicable.
* 該当する場合、EVPN および非 EVPN ISF SAFI ルート全体での ECMP 転送をサポートします。
For a given prefix received via one or more non-EVPN ISF routes, the standard BGP best-path selection procedure, as defined in [RFC4271], is applied to determine the "non-EVPN best paths". Similarly, for a given prefix received via one or more EVPN ISF routes, the same procedure is applied to determine the "EVPN best paths".
1 つ以上の非 EVPN ISF ルート経由で受信した特定のプレフィックスについては、[RFC4271] で定義されている標準の BGP ベスト パス選択手順が適用されて、「非 EVPN ベスト パス」が決定されます。同様に、1 つ以上の EVPN ISF ルート経由で受信された特定のプレフィックスに対して、同じ手順が適用されて「EVPN ベスト パス」が決定されます。
When both EVPN and non-EVPN ISF routes are present for the same prefix within a single IP-VRF, the PE MUST perform a tie-breaking selection procedure on the union of these best-path sets. The process treats all candidate ISF routes as equally preferable initially, then iteratively removes routes until a single best path (or a valid ECMP set) remains.
EVPN と非 EVPN ISF ルートの両方が単一の IP-VRF 内の同じプレフィックスに存在する場合、PE はこれらの最適パス セットの結合に対してタイブレーク選択手順を実行する必要があります。このプロセスでは、最初はすべての候補 ISF ルートが同等に好ましいものとして扱われ、その後、単一の最適パス (または有効な ECMP セット) が残るまでルートが繰り返し削除されます。
The selection procedure MUST follow the standard route selection rules defined in [RFC4271], with the following additional rules and exceptions applied in the specified order:
選択手順は、[RFC4271] で定義されている標準ルート選択ルールに従わなければなりません (MUST)。ただし、次の追加ルールと例外が指定された順序で適用されます。
1. Immediately after applying the Local Preference comparison step from [RFC4271], the PE MUST remove from consideration any routes that do not have the shortest D-PATH Path Attribute. Routes with no D-PATH Path Attribute are considered to have a D-PATH length of zero. This rule MUST NOT be applied to ISF routes that are not imported into an IP-VRF.
1. [RFC4271] のローカル設定比較ステップを適用した直後に、PE は最短の D-PATH パス属性を持たないルートを考慮から削除しなければなりません (MUST)。D-PATH パス属性のないルートは、D-PATH 長がゼロであるとみなされます。このルールは、IP-VRF にインポートされていない ISF ルートに適用してはなりません。
2. After applying Rule 1, the standard selection steps in [RFC4271] MUST continue in order.
2. ルール 1 を適用した後、[RFC4271] の標準選択ステップを順番に続行しなければなりません (MUST)。
3. If, after the previous steps, one or more candidate routes remain and at least one of them is an EVPN MAC/IP Advertisement route (EVPN Route Type 2), then all EVPN IP Prefix routes (EVPN Route Type 5) MUST be removed from consideration.
3. 前の手順の後、1 つ以上の候補ルートが残り、そのうちの少なくとも 1 つが EVPN MAC/IP アドバタイズメント ルート (EVPN ルート タイプ 2) である場合、すべての EVPN IP プレフィックス ルート (EVPN ルート タイプ 5) を考慮から削除する必要があります。
4. If ECMP is enabled by policy and the remaining candidate routes after Steps 1 through 3 include both EVPN and non-EVPN paths, then both paths MUST be retained. If ECMP is not enabled, and such a case arises, the EVPN path MUST be selected, and the non-EVPN path MUST be removed from consideration.
4. ECMP がポリシーによって有効化されており、ステップ 1 ～ 3 の後の残りの候補ルートに EVPN パスと非 EVPN パスの両方が含まれている場合、両方のパスを保持する必要があります。ECMP が有効になっておらず、そのような状況が発生した場合は、EVPN パスを選択しなければならず、非 EVPN パスは考慮から削除しなければなりません。
This procedure extends the standard BGP best-path selection behavior as specified in [RFC4271] for IPVPN and EVPN IP Prefix routes by incorporating D-PATH-based tie-breaking to prefer routes that traverse the fewest Gateway PEs or domains. These rules MUST NOT be applied to routes received under AFI/SAFI combinations other than IPVPN or EVPN; such routes -- different from IPVPN or EVPN -- get treat-as-withdraw procedures if they are received with a D-PATH Path Attribute, as described in Section 4.
この手順は、D-PATH ベースのタイブレークを組み込むことにより、IPVPN および EVPN IP プレフィックス ルートに対して [RFC4271] で指定されている標準の BGP ベスト パス選択動作を拡張し、最も少ないゲートウェイ PE またはドメインを通過するルートを優先します。これらのルールは、IPVPN または EVPN 以外の AFI/SAFI の組み合わせで受信したルートに適用してはなりません。このようなルートは、IPVPN や EVPN とは異なり、セクション 4 で説明されているように、D-PATH パス属性を使用して受信された場合、引き出しとして扱う手順が適用されます。
Example 1: PE1 receives three candidate routes for prefix IP1/32, all eligible for import into IP-VRF-1:
例 1: PE1 は、プレフィックス IP1/32 の 3 つの候補ルートを受け取り、すべて IP-VRF-1 へのインポートに適格です。
{SAFI=EVPN, RT-2, Local-Pref=100, AS_PATH=(65536,65537)}
{SAFI=EVPN, RT-5, Local-Pref=100, AS_PATH=(65536,65537)}
{SAFI=128, Local-Pref=100, AS_PATH=(65536,65537)}
Selected route:
選択したルート:
{SAFI=EVPN, RT-2, Local-Pref=100, AS_PATH=(65536,65537)}
This outcome is due to Step 3 above, which gives preference to Route Type 2 when both Type 2 and Type 5 EVPN routes exist.
この結果は、タイプ 2 とタイプ 5 の EVPN ルートの両方が存在する場合にルート タイプ 2 を優先する上記のステップ 3 によるものです。
Example 2: PE1 receives two candidate routes for prefix IP2/24, both eligible for import into IP-VRF-1:
例 2: PE1 は、プレフィックス IP2/24 の 2 つの候補ルートを受け取り、どちらも IP-VRF-1 へのインポートに適格です。
{SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS_PATH=(65536,65537), MED=10}
{SAFI=128, D-PATH=(6500:1:EVPN,6500:2:IPVPN), AS_PATH=(65537), MED=200}
Selected route:
選択したルート:
{SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS_PATH=(65536,65537), MED=10}
This result is due to Step 1 above, which prefers the route with the shortest D-PATH.
この結果は、D-PATH が最も短いルートを優先する上記のステップ 1 によるものです。
As described in Section 3, composite PEs are typically used in tenant networks where EVPN and IPVPN are both used to provide ISF within the same composite domain.
セクション 3 で説明したように、複合 PE は通常、EVPN と IPVPN の両方が同じ複合ドメイン内で ISF を提供するために使用されるテナント ネットワークで使用されます。
Figure 8 depicts an example of a composite domain, where PE1/PE2/PE4 are composite PEs (they support EVPN and IPVPN ISF SAFIs on their peering to the RR), and PE3 is a regular IPVPN PE.
図 8 は、複合ドメインの例を示しています。PE1/PE2/PE4 は複合 PE (RR へのピアリングで EVPN および IPVPN ISF SAFI をサポートします)、PE3 は通常の IPVPN PE です。
+-----------------------------------+
| |
| MPLS/SRv6 IPVPN PE3
| Network +----------+ IP3/24
| IPVPN |+------+ | +---+
| +----->||IP-VRF|------|CE3|
Composite PE1 | |+------+ | +---+
+---------------+ | +----------+
| +------+ | EVPN v |
| |IP-VRF| | IPVPN +--+ |
| +----| | | <------> |RR| |
+---+ | | +------+ | +--+ Composite PE4
|CE2|----|MAC-VRF| | ^ ^ +---------+ IP4/24
+---+ | +-------+ | EVPN | | EVPN |+------+ | +---+
+---|-----------+ IPVPN | | IPVPN ||IP-VRF|-----|CE4|
| | +----+ +-------->|+------+ | +---+
IP1/24 | | v +---------+
+---+ | | +---------------+ |
|CE1|--+ +----| +------+ +--------------+
+---+ | |IP-VRF| |
| | +----| | |
| | | +------+ |
+--------------|MAC-VRF| |
| +-------+ |
+---------------+
Composite PE2
Figure 8: Composite PE Example
図 8: 複合 PE の例
In a composite domain comprising both composite and regular PEs, the following behaviors apply:
複合 PE と通常の PE の両方で構成される複合ドメインでは、次の動作が適用されます。
Prefix Advertisement Consistency:
プレフィックス アドバタイズメントの一貫性:
Composite PEs MUST advertise the same IP prefixes using each ISF SAFI to the RR, assuming the same RR is used for both ISF SAFIs. For example, as shown in Figure 8, the prefix IP1/24 is advertised by PE1 and PE2 to the RR in two separate Network Layer Reachability Information (NLRI) entries: one for AFI/SAFI 1/128 (IPVPN) and another for EVPN. If both routes are advertised with the same set of BGP Path Attributes, the receiving composite PE will select the EVPN route over the IPVPN route, following the route selection procedures defined in Section 6. Prioritizing the advertisement of the EVPN route before the IPVPN route is an OPTIONAL optimization. This ensures that the EVPN route is more likely to be selected first, avoiding unnecessary replacement if the IPVPN route arrives later.
複合 PE は、両方の ISF SAFI で同じ RR が使用されることを前提として、各 ISF SAFI を使用して同じ IP プレフィックスを RR にアドバタイズしなければなりません (MUST)。たとえば、図 8 に示すように、プレフィックス IP1/24 は、PE1 および PE2 によって 2 つの別個のネットワーク層到達可能性情報 (NLRI) エントリで RR にアドバタイズされます。1 つは AFI/SAFI 1/128 (IPVPN) 用で、もう 1 つは EVPN 用です。両方のルートが同じ BGP パス属性セットでアドバタイズされる場合、受信コンポジット PE は、セクション 6 で定義されたルート選択手順に従って、IPVPN ルートよりも EVPN ルートを選択します。IPVPN ルートよりも先に EVPN ルートのアドバタイズメントを優先することは、オプションの最適化です。これにより、EVPN ルートが最初に選択される可能性が高くなり、IPVPN ルートが後で到着した場合の不必要な置換が回避されます。
Route Reflector SAFI-Specific Forwarding Behavior:
ルート リフレクター SAFI 固有の転送動作:
The RR does not forward EVPN routes to peers for which the EVPN SAFI is not enabled and likewise does not forward IPVPN routes to peers lacking IPVPN SAFI support. For instance, in Figure 8, the RR does not forward EVPN routes to PE3 if the EVPN SAFI is not enabled on its BGP session with PE3. However, the IPVPN routes are forwarded to all PEs since they all have IPVPN SAFI enabled.
RR は、EVPN SAFI が有効になっていないピアに EVPN ルートを転送しません。また、同様に、IPVPN SAFI サポートが不足しているピアに IPVPN ルートを転送しません。たとえば、図 8 では、PE3 との BGP セッションで EVPN SAFI が有効になっていない場合、RR は EVPN ルートを PE3 に転送しません。ただし、IPVPN SAFI がすべて有効になっているため、IPVPN ルートはすべての PE に転送されます。
IPVPN PE Route Processing:
IPVPN PE ルート処理:
Regular IPVPN PEs process and import IPVPN routes as specified in [RFC4364] and [RFC9252]. For example, PE3 receives only the IPVPN route for prefix IP1/24 and resolves the BGP next hop to an MPLS/ SRv6 tunnel (with IP payload) toward PE1 and/or PE2.
通常の IPVPN PE は、[RFC4364] および [RFC9252] で指定されているように IPVPN ルートを処理およびインポートします。たとえば、PE3 はプレフィックス IP1/24 の IPVPN ルートのみを受信し、BGP ネクスト ホップを PE1 および/または PE2 への MPLS/SRv6 トンネル (IP ペイロード付き) に解決します。
Composite PE Route Selection:
複合 PE ルートの選択:
Composite PEs MUST perform route selection for prefixes received via multiple ISF SAFIs, applying the procedures described in Section 6:
複合 PE は、セクション 6 で説明されている手順を適用して、複数の ISF SAFI 経由で受信したプレフィックスのルート選択を実行しなければなりません (MUST)。
* For example, PE4 receives prefix IP1/24 via both an EVPN route and a non-EVPN ISF route (e.g., an IPVPN route). Route selection is performed as specified in Section 6.
* たとえば、PE4 は、EVPN ルートと非 EVPN ISF ルート (IPVPN ルートなど) の両方を介してプレフィックス IP1/24 を受信します。ルート選択はセクション 6 で指定されているとおりに実行されます。
* If the EVPN route is selected, PE4 resolves the BGP next hop to a tunnel (which may carry either Ethernet or IP payloads) to PE1 and/or PE2. As described in Section 3, the tunnel type used between EVPN PEs depends on the supported model per [RFC9136].
* EVPN ルートが選択されている場合、PE4 は BGP ネクスト ホップを PE1 および/または PE2 へのトンネル (イーサネットまたは IP ペイロードを伝送できる) に解決します。セクション 3 で説明されているように、EVPN PE 間で使用されるトンネル タイプは、[RFC9136] に従ってサポートされているモデルによって異なります。
* Other composite PEs (e.g., PE1 and PE2) receiving the same prefix via both EVPN and IPVPN SAFIs must also apply the route selection process defined in Section 6.
* EVPN と IPVPN SAFI の両方を介して同じプレフィックスを受信する他の複合 PE (PE1 と PE2 など) も、セクション 6 で定義されているルート選択プロセスを適用する必要があります。
Forwarding Behavior Based on Selected Route:
選択したルートに基づく転送動作:
Once a route has been selected for a given IP prefix, packet forwarding MUST follow the forwarding rules associated with the AFI/SAFI of the selected route.
特定の IP プレフィックスに対してルートが選択されたら、パケット転送は、選択されたルートの AFI/SAFI に関連付けられた転送ルールに従わなければなりません (MUST)。
Applicability of EVPN Forwarding Enhancements:
EVPN 転送拡張機能の適用可能性:
In composite domains such as the one depicted in Figure 8, the advanced forwarding features provided by EVPN are available only to composite and EVPN-capable PEs that select an EVPN IP Prefix route as the best path. These enhancements are not available to IPVPN-only PEs. For example, if PE1 advertises IP1/24 using both EVPN and IPVPN routes, and the EVPN route is selected as the best path, only composite PEs such as PE2 and PE4 can leverage EVPN-specific recursive resolution and forwarding mechanisms [RFC9136]. IPVPN PEs, such as PE3, cannot utilize these capabilities. Consequently, the benefits of EVPN-based indirection and route resolution in large-scale deployments may not be available uniformly across all PEs in the network.
図 8 に示すような複合ドメインでは、EVPN によって提供される高度な転送機能は、EVPN IP プレフィックス ルートを最適パスとして選択する複合および EVPN 対応 PE でのみ利用できます。これらの拡張機能は、IPVPN 専用 PE では利用できません。たとえば、PE1 が EVPN と IPVPN ルートの両方を使用して IP1/24 をアドバタイズし、EVPN ルートが最適パスとして選択された場合、PE2 や PE4 などの複合 PE のみが EVPN 固有の再帰的解決および転送メカニズム [RFC9136] を利用できます。PE3 などの IPVPN PE は、これらの機能を利用できません。したがって、大規模展開における EVPN ベースの間接化とルート解決の利点は、ネットワーク内のすべての PE で均一に利用できない場合があります。
As defined in Section 3, a gateway PE is an Interworking PE that connects two or more domains and facilitates the re-origination of ISF routes between those domains. Typical examples include data center gateway devices that interconnect domains utilizing different ISF SAFIs, such as EVPN and IPVPN, for the same tenant network.
セクション 3 で定義されているように、ゲートウェイ PE は、2 つ以上のドメインを接続し、それらのドメイン間の ISF ルートの再発信を容易にするインターワーキング PE です。典型的な例には、同じテナント ネットワークに対して、EVPN や IPVPN などの異なる ISF SAFI を利用してドメインを相互接続するデータ センター ゲートウェイ デバイスが含まれます。
The gateway PE procedures specified in this document define the mechanisms required to support ISF route interconnection across such domains. These procedures extend the concept of a gateway PE beyond the scope of Section 3, which focuses on Layer 2 interconnection by providing an analogous interconnection model for ISF route exchange at Layer 3.
この文書で指定されているゲートウェイ PE プロシージャは、そのようなドメイン間の ISF ルート相互接続をサポートするために必要なメカニズムを定義します。これらの手順は、セクション 3 の範囲を超えてゲートウェイ PE の概念を拡張します。セクション 3 では、レイヤー 3 での ISF ルート交換に類似した相互接続モデルを提供することで、レイヤー 2 の相互接続に焦点を当てています。
The procedures described in this section apply to both of the following scenarios:
このセクションで説明する手順は、次の両方のシナリオに適用されます。
* Interconnection between domains utilizing different ISF SAFIs (e.g., EVPN to IPVPN).
* 異なる ISF SAFI を利用したドメイン間の相互接続 (例: EVPN から IPVPN)。
* Interconnection between domains utilizing the same ISF SAFI (e.g., EVPN to EVPN).
* 同じ ISF SAFI を利用したドメイン間の相互接続 (例: EVPN から EVPN)。
Figure 9 provides an illustrative example of this model, wherein PE1 and PE2 (as well as PE3 and PE4) operate as gateway PEs interconnecting different domains associated with the same tenant.
図 9 は、このモデルの例を示しています。PE1 と PE2 (および PE3 と PE4) は、同じテナントに関連付けられた異なるドメインを相互接続するゲートウェイ PE として動作します。
<----EVPN----> <----------IPVPN---------> <----EVPN---->
6500:1:EVPN 6500:2:IPVPN 6500:3:EVPN
<DOMAIN-ID:ISF_SAFI_TYPE>
+-----------------------+
Gateway PE1 Gateway PE3
+----------+ +----------+
+-----------|+------+ | MPLS tnls |+------+ |------------+
| ||IP-VRF| | SRv6 ||IP-VRF| | |
PE5 |+------+ | |+------+ | PE6
+------+ +----------+ +----------+ +------+
|IP-VRF| NVO tnls | | | | NVO tnls |IP-VRF|
| | | | | | | |
+------+ +----------+ +----------+ +------+
IP1/24--> |+------+ | |+------+ | |
| ||IP-VRF| | ||IP-VRF| | |
+-----------|+------+ | |+------+ |------------+
+----------+ +----------+
Gateway PE2 +------+ Gateway PE4
+-------|IP-VRF|---------+
| |
+------+
PE7
Figure 9: Gateway PE Example
図 9: ゲートウェイ PE の例
Note: "tnls" refers to "tunnels".
注: 「tnls」は「トンネル」を指します。
A gateway PE that is enabled for two ISF SAFIs on the same IP-VRF, referred to here as SAFI x and SAFI y, MUST follow the procedures described below for re-originating routes between domains.
同じ IP-VRF 上の 2 つの ISF SAFI (ここでは SAFI x および SAFI y と呼びます) に対して有効になっているゲートウェイ PE は、ドメイン間のルートを再発信するために以下で説明する手順に従わなければなりません (MUST)。
1. A gateway PE that imports an ISF SAFI x route for prefix P into an IP-VRF MUST export P using ISF SAFI y if all of the following conditions are met:
1. プレフィックス P の ISF SAFI x ルートを IP-VRF にインポートするゲートウェイ PE は、次の条件がすべて満たされる場合、ISF SAFI y を使用して P をエクスポートしなければなりません。
a. The route for P is installed in the IP-VRF, indicating that the SAFI x route is well-formed, valid, and selected as the best route.
a. P のルートは IP-VRF にインストールされており、SAFI x ルートが整形式で有効であり、最適なルートとして選択されていることを示します。
b. The PE has an active BGP session with a peer supporting SAFI y, enabled for the same IP-VRF.
b. PE には、同じ IP-VRF に対して有効になっている SAFI y をサポートするピアとのアクティブな BGP セッションがあります。
c. Export policy permits the advertisement of the route.
c. エクスポート ポリシーによりルートのアドバタイズが許可されます。
d. SAFI x and SAFI y are valid ISF SAFIs as defined in Section 3. SAFI x and SAFI y MAY be the same.
d. SAFI x および SAFI y は、セクション 3 で定義されている有効な ISF SAFI です。SAFI x と SAFI y は同じであってもよい (MAY)。
Example: In Figure 9, Gateway PEs PE1 and PE2 receive an EVPN IP Prefix route for prefix IP1/24, install the route in their respective IP-VRFs, and re-advertise it using IPVPN.
例：図 9 では、ゲートウェイ PE PE1 および PE2 がプレフィックス IP1/24 の EVPN IP プレフィックス ルートを受信し、そのルートをそれぞれの IP-VRF にインストールし、IPVPN を使用して再アドバタイズします。
2. A gateway PE that receives an ISF SAFI x route for prefix P into an IP-VRF MUST NOT export P using SAFI y under any of the following conditions:
2. プレフィックス P の ISF SAFI x ルートを IP-VRF に受信するゲートウェイ PE は、次のいずれかの条件下で SAFI y を使用して P をエクスポートしてはなりません (MUST NOT)。
a. The SAFI x route is not well-formed or valid. Criteria for route validity are defined in the corresponding ISF SAFI specification. For example, an EVPN IP Prefix route that contains both a non-zero Ethernet Segment Identifier (ESI) and a Gateway IP address is invalid, as specified in [RFC9136], Section 3.2.
a. SAFI x ルートは整形式ではないか、有効ではありません。ルートの有効性の基準は、対応する ISF SAFI 仕様で定義されます。たとえば、[RFC9136] セクション 3.2 で規定されているように、ゼロ以外のイーサネット セグメント識別子 (ESI) とゲートウェイ IP アドレスの両方を含む EVPN IP プレフィックス ルートは無効です。
b. The D-PATH Path Attribute of the SAFI x route includes one or more DOMAIN-ID values locally configured on the gateway PE for the associated IP-VRF. In this case, the route is considered a looped ISF route, as described in Section 4, and MUST NOT be exported using SAFI y.
b. SAFI x ルートの D-PATH パス属性には、関連付けられた IP-VRF のゲートウェイ PE 上でローカルに設定された 1 つ以上の DOMAIN-ID 値が含まれます。この場合、セクション 4 で説明されているように、ルートはループされた ISF ルートとみなされ、SAFI y を使用してエクスポートしてはなりません (MUST NOT)。
If the export conditions are satisfied, the gateway PE MUST advertise prefix P using ISF SAFI y in accordance with the following procedures:
エクスポート条件が満たされる場合、ゲートウェイ PE は、次の手順に従って、ISF SAFI y を使用してプレフィックス P をアドバタイズしなければなりません (MUST)。
1. If Uniform Propagation Mode (see Section 5.2) is enabled, the gateway PE MUST follow the procedures defined in Section 5.2, and the gateway PE MUST include the D-PATH Path Attribute when SAFI y is either IPVPN or EVPN. This enables loop detection at downstream gateway PEs.
1. 均一伝播モード (セクション 5.2 を参照) が有効な場合、ゲートウェイ PE はセクション 5.2 で定義された手順に従わなければなりません (MUST)。SAFI y が IPVPN または EVPN の場合、ゲートウェイ PE は D-PATH パス属性を含めなければなりません (MUST)。これにより、ダウンストリーム ゲートウェイ PE でのループ検出が有効になります。
When re-originating an ISF route, the gateway PE MUST prepend a <DOMAIN-ID:ISF_SAFI_TYPE> element to the received D-PATH Path Attribute. The DOMAIN-ID reflects the domain from which the route was received, and the ISF_SAFI_TYPE reflects the SAFI of the received route.
ISF ルートを再発信する場合、ゲートウェイ PE は、受信した D-PATH パス属性の先頭に <DOMAIN-ID:ISF_SAFI_TYPE> 要素を追加しなければなりません (MUST)。DOMAIN-ID はルートの受信元のドメインを反映し、ISF_SAFI_TYPE は受信したルートの SAFI を反映します。
If the received route does not include a D-PATH Path Attribute, the gateway PE MUST create and attach a new D-PATH Path Attribute containing a single segment: the <DOMAIN-ID:ISF_SAFI_TYPE> corresponding to the received route.
受信したルートに D-PATH パス属性が含まれていない場合、ゲートウェイ PE は、単一のセグメント (受信したルートに対応する <DOMAIN-ID:ISF_SAFI_TYPE>) を含む新しい D-PATH パス属性を作成して添付しなければなりません。
Example: In Figure 9, gateway PEs PE1 and PE2 receive an EVPN IP Prefix route from PE5 that does not include a D-PATH Path Attribute. PE1 and PE2 add domain <6500:1:EVPN> to form the new D-PATH. Gateway PEs PE3 and PE4, upon re-advertising the route, prepend <6500:2:IPVPN>, resulting in PE6 receiving the route with D-PATH {<6500:2:IPVPN>, <6500:1:EVPN>}. This information is then used by PE6 in BGP path selection.
例: 図 9 では、ゲートウェイ PE PE1 および PE2 は、D-PATH パス属性を含まない EVPN IP プレフィックス ルートを PE5 から受信します。PE1 と PE2 はドメイン <6500:1:EVPN> を追加して、新しい D-PATH を形成します。ゲートウェイ PE PE3 および PE4 は、ルートを再アドバタイズするときに <6500:2:IPVPN> を先頭に付加し、その結果、PE6 は D-PATH {<6500:2:IPVPN>, <6500:1:EVPN>} でルートを受信します。この情報は、PE6 による BGP パスの選択に使用されます。
2. The gateway PE uses the RD of the IP-VRF when re-advertising prefix P via ISF SAFI y.
2. ゲートウェイ PE は、ISF SAFI y を介してプレフィックス P を再アドバタイズするときに、IP-VRF の RD を使用します。
3. The encapsulation-specific context (e.g., label) allocation is a local matter. The gateway PE MAY use per-VRF, per-prefix, or other label allocation models.
3. カプセル化固有のコンテキスト (ラベルなど) の割り当てはローカルの問題です。ゲートウェイ PE は、VRF ごと、プレフィックスごと、またはその他のラベル割り当てモデルを使用してもよい（MAY）。
4. The gateway PE MUST support the use of distinct RT sets per domain on the same IP-VRF. If multiple domains associated with a tenant use different RT sets, the gateway PE MUST be capable of importing and exporting routes according to each domain's RT configuration.
4. ゲートウェイ PE は、同じ IP-VRF 上のドメインごとに異なる RT セットの使用をサポートしなければなりません。テナントに関連付けられた複数のドメインが異なる RT セットを使用する場合、ゲートウェイ PE は各ドメインの RT 設定に従ってルートをインポートおよびエクスポートできなければなりません (MUST)。
5. Although Figure 9 illustrates a scenario with only two domains per gateway PE, gateway PEs may interconnect more than two domains.
5. 図 9 は、ゲートウェイ PE あたり 2 つのドメインのみのシナリオを示していますが、ゲートウェイ PE は 3 つ以上のドメインを相互接続する場合があります。
6. There is no restriction on the number of gateway PEs that a given prefix P may traverse before reaching its destination.
6. 特定のプレフィックス P が宛先に到達する前に通過できるゲートウェイ PE の数に制限はありません。
Informative Note: If prefix P is originated in an EVPN domain and subsequently traverses one or more non-EVPN ISF SAFI domains, it will lose EVPN-specific attributes used for advanced EVPN procedures. For example, if PE1 advertises prefix IP1/24 along with a non-zero ESI (for recursive resolution to that ESI), the ESI value will be reset to zero by the time the route reaches PE6, as it passed through an ISF SAFI domain that is not EVPN-capable. Consequently, certain EVPN-specific functionalities may not be preserved end to end.
参考注記: プレフィックス P が EVPN ドメインで発信され、その後 1 つ以上の非 EVPN ISF SAFI ドメインを通過する場合、高度な EVPN 手順に使用される EVPN 固有の属性が失われます。たとえば、PE1 がゼロ以外の ESI（ESI への再帰解決のため）とともにプレフィックス IP1/24 をアドバタイズする場合、ルートは EVPN 対応ではない ISF SAFI ドメインを通過するため、ルートが PE6 に到達するまでに ESI 値はゼロにリセットされます。その結果、特定の EVPN 固有の機能がエンドツーエンドで維持されない可能性があります。
While network deployments involving Interworking PEs may align with the scenarios described in Sections 7 and 8, there are cases where a combination of both gateway PE and composite PE functionality is required. Figure 10 illustrates an example in which gateway PEs also operate as composite PEs. In such scenarios, the devices must not only re-originate ISF routes between domains, such as between EVPN and IPVPN SAFIs or across multiple EVPN domains, but also interoperate with IPVPN-only PEs within domains that include a mix of composite and IPVPN-only PEs.
インターワーキング PE を含むネットワーク展開は、セクション 7 および 8 で説明したシナリオと一致する可能性がありますが、ゲートウェイ PE と複合 PE の両方の機能の組み合わせが必要になる場合があります。図 10 は、ゲートウェイ PE が複合 PE としても動作する例を示しています。このようなシナリオでは、デバイスは、EVPN と IPVPN SAFI の間、または複数の EVPN ドメイン間など、ドメイン間で ISF ルートを再発信するだけでなく、複合 PE と IPVPN 専用 PE が混在するドメイン内の IPVPN 専用 PE と相互運用する必要もあります。
+-----------------------------------+
| |
| MPLS IPVPN PE3
| Network +---------+
| IPVPN |+------+ |
| +----->||IP-VRF|---TS3
(GW+composite) PE1 | |+------+ |
+---------------+ | +---------+
| +------+ | EVPN v |
| |IP+VRF| | IPVPN +--+ |
| +----| | | <------>|RR| |
+--------| | +------+ | +--+ Composite PE4
| | |MAC+VRF| | ^ ^ +---------+
| | +-------+ | EVPN | | EVPN |+------+ |
+----+ +---------------+ IPVPN | | IPVPN ||IP-VRF|---TS4
TS1-|NVE1| | +----+ +------->|+------+ |
+----+ | v +---------+
| EVPN DC | +---------------+ |
| NVO tnls +----| +------+ |-------------+
| | |IP+VRF| |
| | +----| | |
| | | +------+ |
| +----+ | |MAC+VRF| |
+-----|NVE2|---------| +-------+ |
+----+ +---------------+
| (GW+composite) PE2
TS2
Figure 10: Gateway and Composite Combined Functions Example
図 10: ゲートウェイとコンポジットの結合機能の例
Note: "tnls" refers to "tunnels".
注: 「tnls」は「トンネル」を指します。
In Figure 10, PE1 and PE2 follow the procedures defined in Sections 7 and 8. Unlike the scenario described in Section 8, PE1 and PE2 are additionally required to re-originate ISF routes between EVPN domains (i.e., EVPN-to-EVPN), in addition to EVPN-to-IPVPN re-origination. It is important to note that PE1 and PE2 will receive the IP prefix associated with TS4 via both IPVPN and EVPN IP Prefix routes. When re-advertising the selected route to NVE1 and NVE2, PE1 and PE2 MUST apply the D-PATH handling rules and related attribute processing as described in Section 6 ("Route Selection Process for ISF Routes").
図 10 では、PE1 と PE2 はセクション 7 と 8 で定義された手順に従います。セクション 8 で説明したシナリオとは異なり、PE1 と PE2 は、EVPN から IPVPN への再発信に加えて、EVPN ドメイン間 (つまり、EVPN から EVPN) の ISF ルートを再発信することも追加で必要です。PE1 と PE2 は、IPVPN と EVPN IP プレフィックス ルートの両方を介して、TS4 に関連付けられた IP プレフィックスを受信することに注意することが重要です。選択したルートを NVE1 および NVE2 に再アドバタイズする場合、PE1 および PE2 は、セクション 6 (「ISF ルートのルート選択プロセス」) で説明されているように、D-PATH 処理ルールと関連する属性処理を適用しなければなりません。
BGP speakers following this specification MUST adhere to the following error-handling procedures when processing ISF routes:
この仕様に従う BGP スピーカーは、ISF ルートを処理するときに次のエラー処理手順に従わなければなりません。
* Any BGP UPDATE message for an ISF route that includes a D-PATH Path Attribute MUST be handled in accordance with the error-handling rules defined in Section 4 of this document.
* D-PATH パス属性を含む ISF ルートの BGP UPDATE メッセージは、この文書のセクション 4 で定義されているエラー処理規則に従って処理されなければなりません (MUST)。
* All received BGP UPDATE messages for ISF routes MUST conform to the general error-handling procedures specified in [RFC7606].
* ISF ルートに対して受信したすべての BGP UPDATE メッセージは、[RFC7606] で指定されている一般的なエラー処理手順に準拠しなければなりません (MUST)。
* This specification introduces no new error-handling behaviors for BGP UPDATE messages that contain NLRI and BGP Path Attributes defined in other specifications. Implementations SHOULD apply the relevant error-handling rules specified for each supported route type.
* この仕様では、他の仕様で定義されている NLRI および BGP パス属性を含む BGP UPDATE メッセージに対する新しいエラー処理動作は導入されていません。実装では、サポートされているルート タイプごとに指定された関連するエラー処理ルールを適用する必要があります (SHOULD)。
If a gateway PE is configured to propagate BGP Path Attributes for ISF routes between domains, the procedures specified in Section 5.2 are intended to ensure that receiving BGP speakers do not encounter UPDATE messages containing well-formed but semantically inappropriate BGP Path Attributes. However, if a gateway PE incorrectly propagates such attributes in violation of the procedures in Section 5.2, receiving PEs MUST apply the error-handling rules defined in the applicable specifications for the relevant route type and attribute.
ゲートウェイ PE がドメイン間で ISF ルートの BGP パス属性を伝播するように構成されている場合、セクション 5.2 で指定されている手順は、受信側の BGP スピーカーが、整形式ではあるが意味的に不適切な BGP パス属性を含む UPDATE メッセージに遭遇しないことを保証することを目的としています。ただし、ゲートウェイ PE がセクション 5.2 の手順に違反してそのような属性を誤って伝播した場合、受信側 PE は関連するルート タイプと属性に該当する仕様で定義されているエラー処理ルールを適用しなければなりません (MUST)。
The following are examples of such scenarios and their handling:
以下は、そのようなシナリオとその処理の例です。
* If a gateway PE erroneously propagates the BGP Encapsulation Extended Community or the equivalent Encapsulation TLV in the Tunnel Encapsulation attribute [RFC9012] from one EVPN domain to another, the receiving PE MAY receive two encapsulation indications with different values. In such a case, the PE MUST follow the procedures in [RFC8365], which permit signaling multiple encapsulation types. As specified in [RFC9012], encapsulations carried via the Tunnel Encapsulation attribute MUST be treated as equivalent to those conveyed via the Encapsulation Extended Community.
* ゲートウェイ PE が BGP カプセル化拡張コミュニティまたはトンネル カプセル化属性 [RFC9012] の同等のカプセル化 TLV をある EVPN ドメインから別の EVPN ドメインに誤って伝播した場合、受信側 PE は異なる値を持つ 2 つのカプセル化指示を受信してもよい(MAY)。このような場合、PE は複数のカプセル化タイプのシグナリングを許可する [RFC8365] の手順に従わなければなりません (MUST)。[RFC9012] で規定されているように、Tunnel Encapsulation 属性を介して伝送されるカプセル化は、Encapsulation Extended Community を介して伝送されるカプセル化と同等として扱われなければなりません (MUST)。
* If a gateway PE propagates an EVPN Extended Community from an EVPN domain into an IPVPN domain, the receiving IPVPN PE MUST ignore such communities, as their semantics are not applicable to the IPVPN SAFI.
* ゲートウェイ PE が EVPN 拡張コミュニティを EVPN ドメインから IPVPN ドメインに伝播する場合、受信側 IPVPN PE は、そのセマンティクスが IPVPN SAFI に適用されないため、そのようなコミュニティを無視しなければなりません (MUST)。
* If a gateway PE erroneously propagates a BGP Prefix-SID attribute containing SRv6 Service TLVs [RFC9252] for an ISF route between domains, and the receiving PE receives multiple SRv6 TLV instances, it MUST apply the procedures specified in [RFC9252] for resolving multiple TLVs.
* ゲートウェイ PE がドメイン間の ISF ルートの SRv6 サービス TLV [RFC9252] を含む BGP プレフィックス SID 属性を誤って伝播し、受信側 PE が複数の SRv6 TLV インスタンスを受信した場合、複数の TLV を解決するために [RFC9252] で指定されている手順を適用しなければなりません。
The security considerations outlined in [RFC9136] and [RFC8365] for ISF EVPN routes and [RFC4364] for ISF IPVPN routes are applicable to this specification. In addition, the security considerations sections in [RFC9252] and [RFC7606], as well as the entire text in [RFC4272], are relevant to this document.
ISF EVPN ルートについては [RFC9136] および [RFC8365]、ISF IPVPN ルートについては [RFC4364] で概説されているセキュリティ上の考慮事項が、この仕様に適用されます。さらに、[RFC9252] および [RFC7606] のセキュリティに関する考慮事項のセクション、および [RFC4272] の全文がこの文書に関連します。
This document introduces the D-PATH Path Attribute (Section 4), which provides a mechanism for control plane loop prevention when ISF IPVPN and EVPN routes are re-originated across multiple domains via gateway PEs. When configured and supported correctly, the use of the D-PATH Path Attribute helps prevent both control plane and data plane loops. However, incorrect configuration of DOMAIN-ID values or inconsistent support for D-PATH among gateway PEs may result in false-positive loop detection, traffic discarding, or suboptimal and inconsistent routing behavior. Furthermore, as D-PATH is a transitive BGP attribute, a malicious actor may attempt to inject incorrect domain information that propagates across multiple administrative boundaries.
このドキュメントでは、D-PATH パス属性 (セクション 4) を紹介します。これは、ISF IPVPN および EVPN ルートがゲートウェイ PE を介して複数のドメインにまたがって再発信される場合に、コントロール プレーン ループ防止のメカニズムを提供します。正しく構成およびサポートされている場合、D-PATH パス属性を使用すると、コントロール プレーンとデータ プレーンの両方のループを防ぐことができます。ただし、DOMAIN-ID 値の構成が正しくない場合、またはゲートウェイ PE 間での D-PATH のサポートに一貫性がない場合、誤検知ループの検出、トラフィックの破棄、または最適ではない一貫性のないルーティング動作が発生する可能性があります。さらに、D-PATH は推移的な BGP 属性であるため、悪意のある攻撃者は、複数の管理境界を越えて伝播する誤ったドメイン情報を挿入しようとする可能性があります。
To mitigate such risks, the use of D-PATH is explicitly restricted to IPVPN and EVPN routes within "walled garden" Virtual Private Networks, as specified in Section 4. A PE that conforms to this specification MUST remove the D-PATH Path Attribute prior to advertising a prefix to a CE router in a SAFI 1 (NLRI used for unicast forwarding) route. If a non-upgraded PE that does not support D-PATH receives such a route and is connected to a CE with Internet access, it may erroneously propagate the D-PATH Path Attribute in a SAFI 1 UPDATE to the CE. If the CE further propagates the route, the D-PATH Path Attribute could inadvertently escape into the public Internet.
このようなリスクを軽減するために、セクション 4 で指定されているように、D-PATH の使用は、「ウォールド ガーデン」仮想プライベート ネットワーク内の IPVPN および EVPN ルートに明示的に制限されています。この仕様に準拠する PE は、SAFI 1 (ユニキャスト転送に使用される NLRI) ルートで CE ルーターにプレフィックスをアドバタイズする前に、D-PATH パス属性を削除しなければなりません (MUST)。D-PATH をサポートしないアップグレードされていない PE がそのようなルートを受信し、インターネット アクセスを使用して CE に接続されている場合、SAFI 1 UPDATE 内の D-PATH パス属性が CE に誤って伝播される可能性があります。CE がルートをさらに伝播すると、D-PATH パス属性が誤ってパブリック インターネットに漏洩する可能性があります。
However, the presence of the D-PATH Path Attribute in SAFI 1 routes MUST NOT impact BGP best-path selection for those routes and, as such, cannot introduce routing loops or instability in the Internet. Additionally, BGP speakers beyond the "walled garden" that support D-PATH and receive the attribute in SAFI 1 routes MUST apply the "treat-as-withdraw" behavior, as described in Section 4 and consistent with [RFC7606].
ただし、SAFI 1 ルートに D-PATH パス属性が存在しても、それらのルートの BGP 最適パス選択に影響を与えてはなりません。そのため、インターネットにルーティング ループや不安定性が生じることはありません。さらに、D-PATH をサポートし、SAFI 1 ルートで属性を受け取る「ウォールド ガーデン」を超えた BGP スピーカーは、セクション 4 で説明され、[RFC7606] と一致するように、「撤退として扱う」動作を適用しなければなりません (MUST)。
As a further safeguard, implementations SHOULD enforce local policy on upgraded PEs to discard any ISF EVPN or IPVPN routes received from non-upgraded peers if such routes include a D-PATH Path Attribute to prevent unintended propagation. The mechanism by which an implementation determines that ISF EVPN or IPVPN routes are received from non-upgraded peers is outside the scope of this document.
さらなる安全策として、実装では、意図しない伝播を防ぐために、アップグレードされていないピアから受信した ISF EVPN または IPVPN ルートに D-PATH パス属性が含まれている場合、そのルートを破棄するローカル ポリシーをアップグレードされた PE に適用する必要があります (SHOULD)。ISF EVPN または IPVPN ルートがアップグレードされていないピアから受信されたことを実装が判断するメカニズムについては、このドキュメントの範囲外です。
Section 5.2 of this document introduces Uniform Propagation Mode, which enables gateway PEs to propagate a consistent set of BGP Path Attributes across domain boundaries. This mode enhances operational visibility by preserving attributes end to end along the route path. However, it also introduces the possibility that an attacker could inject malformed or semantically inappropriate, but syntactically correct, attributes that influence BGP path selection in remote domains.
このドキュメントのセクション 5.2 では、ゲートウェイ PE がドメイン境界を越えて一貫した BGP パス属性のセットを伝播できるようにする均一伝播モードを紹介します。このモードでは、ルート パスに沿ってエンドツーエンドで属性を保持することにより、運用の可視性が向上します。ただし、攻撃者が、リモート ドメインでの BGP パスの選択に影響を与える、不正な形式または意味的に不適切だが構文的には正しい属性を挿入する可能性も生じます。
To mitigate this risk, an operator MAY choose to deploy No Propagation Mode (Section 5.1), wherein BGP Path Attributes are re-initialized upon domain transition. While this limits attribute-based attack vectors, it also eliminates the ability of downstream PEs to inspect the original set of BGP Path Attributes as intended by the route originator.
このリスクを軽減するために、オペレータは、BGP パス属性がドメイン移行時に再初期化される、伝播なしモード (セクション 5.1) を展開することを選択してもよい(MAY)。これにより、属性ベースの攻撃ベクトルが制限されますが、ダウンストリーム PE がルート発信元の意図どおりに BGP パス属性の元のセットを検査する機能も排除されます。
Operators SHOULD carefully weigh the trade-offs between visibility and control when selecting the appropriate propagation mode and ensure that policies are in place to validate attribute contents at domain boundaries.
運用者は、適切な伝播モードを選択する際に、可視性と制御の間のトレードオフを慎重に検討し、ドメイン境界で属性の内容を検証するためのポリシーが整備されていることを確認する必要があります。
This document defines a new BGP Path Attribute known as the BGP D-PATH Path Attribute.
このドキュメントでは、BGP D-PATH パス属性として知られる新しい BGP パス属性を定義します。
IANA has assigned a new attribute code type from the "BGP Path Attributes" registry in the "Border Gateway Protocol (BGP) Parameters" registry group as follows:
IANA は、次のように、「ボーダー ゲートウェイ プロトコル (BGP) パラメーター」レジストリ グループの「BGP パス属性」レジストリから新しい属性コード タイプを割り当てました。
+=======+==========================+===========+
| Value | Code | Reference |
+=======+==========================+===========+
| 36 | BGP Domain Path (D-PATH) | RFC 10039 |
+-------+--------------------------+-----------+
Table 2
[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>.
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[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>.
[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>.
[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>.
[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>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[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>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<https://www.rfc-editor.org/info/rfc7311>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[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>.
[RFC9774] Kumari, W., Sriram, K., Hannachi, L., and J. Haas,
"Deprecation of AS_SET and AS_CONFED_SET in BGP",
RFC 9774, DOI 10.17487/RFC9774, May 2025,
<https://www.rfc-editor.org/info/rfc9774>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[IANA-SAFI]
IANA, "SAFI Values",
<https://www.iana.org/assignments/safi-namespace>.
The authors want to thank Russell Kelly, Dhananjaya Rao, Suresh Basavarajappa, Mallika Gautam, Senthil Sathappan, Arul Mohan Jovel, Naveen Tubugere, Mathanraj Petchimuthu, Eduard Vasilenko, Amit Kumar, Mohit Kumar, Lukas Krattiger, Gyan Mishra, and Stephane Litkowski for their reviews and suggestions. Thanks to Sue Hares and Jeff Haas as well for their detailed reviews to clarify the procedures of the D-PATH Path Attribute. The authors want to also especially thank Eric Rosen, Gunter Van de Velde, and Ketan Talaulikar for the thorough reviews that helped raise the quality of the document significantly.
著者らは、Russell Kelly、Dhananjaya Rao、Suresh Basavarajappa、Mallika Gautam、Senthil Sathappan、Arul Mohan Jovel、Naveen Tubugere、Mathanraj Petchimuthu、Eduard Vasilenko、Amit Kumar、Mohit Kumar、Lukas Krattiger、Gyan Mishra、Stephane Litkowski のレビューに感謝します。そして提案。D-PATH パス属性の手順を明確にするための詳細なレビューに対して、Sue Hares と Jeff Haas に感謝します。著者らは、文書の品質を大幅に向上させるのに役立った徹底的なレビューに対して、Eric Rosen、Gunter Van de Velde、および Ketan Talaulikar にも特に感謝したいと思います。
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Ali Sajassi (editor)
Cisco
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
John Drake
Independent
Email: je_drake@yahoo.com
Wen Lin
HPE
Email: wen.lin@hpe.com
James Uttaro
Independent
Email: jimmy.uttaro@gmail.com
Adam Simpson
Nokia
Email: adam.1.simpson@nokia.com