[要約] RFC 7543は、BGP-4のための出力経路フィルタリングにおけるカバリングプレフィックスの要件を定義しています。このRFCの目的は、BGPネットワークでの経路フィルタリングの効率性と正確性を向上させることです。
Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7543 AT&T
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
R. Bonica
Juniper Networks
K. Patel
Cisco Systems
L. Yong
Huawei Technologies
May 2015
Covering Prefixes Outbound Route Filter for BGP-4
BGP-4のプレフィックスアウトバウンドルートフィルターのカバー
Abstract
概要
This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.
このドキュメントでは、カバープレフィックスORF（CP-ORF）と呼ばれる新しいアウトバウンドルートフィルター（ORF）タイプを定義します。 CP-ORFは、仮想HUBおよびスポークVPNに適用できます。また、BGP / MPLSイーサネットVPN（EVPN）ネットワークにも適用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7543.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7543で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability in Virtual Hub-and-Spoke VPNs . . . . . . . . . 10
4.1. Multicast Considerations . . . . . . . . . . . . . . . . 13
5. Applicability in BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 13
6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
A BGP [RFC4271] speaker can send Outbound Route Filters (ORFs) [RFC5291] to a peer. The peer uses ORFs to filter routing updates that it sends to the BGP speaker. Using ORF, a BGP speaker can realize a "route pull" paradigm in which the BGP speaker, on demand, pulls certain routes from the peer.
BGP [RFC4271]スピーカーは、アウトバウンドルートフィルター（ORF）[RFC5291]をピアに送信できます。ピアはORFを使用して、BGPスピーカーに送信するルーティングアップデートをフィルタリングします。 ORFを使用すると、BGPスピーカーは「ルートプル」パラダイムを実現でき、BGPスピーカーはオンデマンドでピアから特定のルートをプルします。
This document defines a new ORF-type, called the Covering Prefixes ORF (CP-ORF). A BGP speaker sends a CP-ORF to a peer in order to pull routes that cover a specified host address. A prefix covers a host address if it can be used to forward traffic towards that host address. Section 3 provides a more complete description of covering prefix selection criteria.
このドキュメントでは、カバープレフィックスORF（CP-ORF）と呼ばれる新しいORFタイプを定義します。 BGPスピーカーは、指定されたホストアドレスをカバーするルートをプルするために、ピアにCP-ORFを送信します。プレフィックスは、そのホストアドレスにトラフィックを転送するために使用できる場合、ホストアドレスをカバーします。セクション3では、プレフィックス選択基準のカバーについてより完全に説明します。
CP-ORF is applicable in Virtual Hub-and-Spoke VPNs [RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN (EVPN) [RFC7432] networks.
CP-ORFは、仮想HUBおよびスポークVPN [RFC7024] [RFC4364]に適用できます。また、適用可能なBGP / MPLSイーサネットVPN（EVPN）[RFC7432]ネットワークにも適用されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o Address Family Identifier (AFI) - defined in [RFC4760]
o アドレスファミリ識別子（AFI）-[RFC4760]で定義
o Subsequent Address Family Identifier (SAFI) - defined in [RFC4760]
o 後続アドレスファミリ識別子（SAFI）-[RFC4760]で定義
o Route Target (RT) - defined in [RFC4364]
o ルートターゲット（RT）-[RFC4364]で定義
o VPN-IP Default Route - defined in [RFC7024]
o VPN-IPデフォルトルート-[RFC7024]で定義
o Virtual Hub (V-hub) - defined in [RFC7024]
o 仮想HUB（Vハブ）-[RFC7024]で定義
o Virtual Spoke (V-spoke) - defined in [RFC7024]
o 仮想スポーク（Vスポーク）-[RFC7024]で定義
o BGP/MPLS Ethernet VPN (EVPN) - defined in [RFC7432]
o BGP / MPLSイーサネットVPN（EVPN）-[RFC7432]で定義
o EVPN Instance (EVI) - defined in [RFC7432]
o EVPNインスタンス（EVI）-[RFC7432]で定義
o MAC - Media Access Control
o MAC-メディアアクセスコントロール
o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement route where the MAC Address Length is set to 48 and the MAC address to 00:00:00:00:00:00
o 不明なMACルート（UMR）-MACアドレス長が48に、MACアドレスが00：00：00：00：00：00に設定されている通常のEVPN MAC / IPアドバタイズルート
o Default MAC Gateway (DMG) - An EVPN Provider Edge (PE) that advertises a UMR
o デフォルトMACゲートウェイ（DMG）-UMRをアドバタイズするEVPNプロバイダーエッジ（PE）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
RFC 5291 augments the BGP ROUTE-REFRESH message so that it can carry ORF entries. When the ROUTE-REFRESH message carries ORF entries, it includes the following fields:
RFC 5291は、ORFエントリを伝送できるようにBGP ROUTE-REFRESHメッセージを拡張します。 ROUTE-REFRESHメッセージにORFエントリが含まれる場合、次のフィールドが含まれます。
o AFI [IANA.AFI]
o AFI [IANA.AFI]
o SAFI [IANA.SAFI]
o ネット[ina。net]
o When-to-refresh (IMMEDIATE or DEFERRED)
o 更新するタイミング（IMMEDIATEまたはDEFERRED）
o ORF Type
o ORFタイプ
o Length (of ORF entries)
o 長さ（ORFエントリーの）
The ROUTE-REFRESH message also contains a list of ORF entries. Each ORF entry contains the following fields:
ROUTE-REFRESHメッセージには、ORFエントリのリストも含まれています。各ORFエントリには、次のフィールドが含まれています。
o Action (ADD, REMOVE, or REMOVE-ALL)
o アクション（ADD、REMOVE、またはREMOVE-ALL）
o Match (PERMIT or DENY)
o 一致（許可または拒否）
The ORF entry may also contain Type-specific information. Type-specific information is present only when the Action is equal to ADD or REMOVE. It is not present when the Action is equal to REMOVE-ALL.
ORFエントリには、タイプ固有の情報が含まれる場合もあります。タイプ固有の情報は、アクションがADDまたはREMOVEと等しい場合にのみ存在します。アクションがREMOVE-ALLと等しい場合は存在しません。
When the BGP ROUTE-REFRESH message carries CP-ORF entries, the following conditions MUST be true:
BGP ROUTE-REFRESHメッセージにCP-ORFエントリが含まれる場合、次の条件が満たされている必要があります。
o The ORF Type MUST be equal to CP-ORF (65).
o ORFタイプはCP-ORF（65）と等しくなければなりません。
o The AFI MUST be equal to IPv4, IPv6, or Layer 2 VPN (L2VPN).
o AFIは、IPv4、IPv6、またはレイヤー2 VPN（L2VPN）と等しい必要があります。
o If the AFI is equal to IPv4 or IPv6, the SAFI MUST be equal to MPLS-labeled VPN address.
o AFIがIPv4またはIPv6と等しい場合、SAFIはMPLSラベル付きVPNアドレスと等しい必要があります。
o If the AFI is equal to L2VPN, the SAFI MUST be equal to BGP EVPN.
o AFIがL2VPNと等しい場合、SAFIはBGP EVPNと等しい必要があります。
o The Match field MUST be equal to PERMIT.
o MatchフィールドはPERMITと等しくなければなりません。
Figure 1 depicts the encoding of the CP-ORF Type-specific information.
図1は、CP-ORFタイプ固有の情報のエンコードを示しています。
+--------------------------------+
| Sequence (32 bits) |
+--------------------------------+
| Minlen (8 bits) |
+--------------------------------+
| Maxlen (8 bits) |
+--------------------------------+
| VPN Route Target (64 bits) |
+--------------------------------+
| Import Route Target (64 bits) |
+--------------------------------+
| Route Type (8 bits) |
+--------------------------------+
| Host Address |
| (0, 32, 48, or 128 bits) |
| .... |
+--------------------------------+
Figure 1: CP-ORF Type-Specific Encoding
図1：CP-ORFタイプ固有のエンコーディング
The CP-ORF recipient uses the following fields to select routes matching the CP-ORF:
CP-ORF受信者は次のフィールドを使用して、CP-ORFに一致するルートを選択します。
o Sequence: the relative position of a CP-ORF entry among other CP-ORF entries
o シーケンス：他のCP-ORFエントリー間のCP-ORFエントリーの相対位置
o Minlen: the minimum length of the selected route (measured in bits)
o Minlen：選択されたルートの最小の長さ（ビット単位で測定）
o Maxlen: the maximum length of the selected route (measured in bits)
o Maxlen：選択されたルートの最大長（ビット単位で測定）
o VPN Route Target: the VPN Route Target carried by the selected route
o VPNルートターゲット：選択されたルートによって運ばれるVPNルートターゲット
o Route Type: the type of the selected route
o ルートタイプ：選択したルートのタイプ
o Host Address: the address covered by the selected route
o ホストアドレス：選択したルートがカバーするアドレス
See Section 3 for details.
詳細については、セクション3を参照してください。
The CP-ORF recipient marks routes that match CP-ORF with the Import Route Target before advertising those routes to the CP-ORF originator. See Section 3 for details.
CP-ORF受信者は、CP-ORF発信者にルートをアドバタイズする前に、CP-ORFとインポートルートターゲットを一致させるルートをマークします。詳細については、セクション3を参照してください。
If the ROUTE-REFRESH AFI is equal to IPv4,
ROUTE-REFRESH AFIがIPv4と等しい場合、
o the value of Minlen MUST be less than or equal to 32;
o Minlenの値は32以下でなければなりません。
o the value of Maxlen MUST be less than or equal to 32;
o Maxlenの値は32以下でなければなりません。
o the value of Minlen MUST be less than or equal to the value of Maxlen;
o Minlenの値はMaxlenの値以下でなければなりません。
o the value of Route Type MUST be 0 (i.e., RESERVED); and
o Route Typeの値は0でなければなりません（つまり、予約済み）。そして
o the Host Address MUST contain exactly 32 bits.
o ホストアドレスは正確に32ビットを含まなければなりません。
If the ROUTE-REFRESH AFI is equal to IPv6,
ROUTE-REFRESH AFIがIPv6と等しい場合、
o the value of Minlen MUST be less than or equal to 128;
o Minlenの値は128以下でなければなりません。
o the value of Maxlen MUST be less than or equal to 128;
o Maxlenの値は128以下でなければなりません。
o the value of Minlen MUST be less than or equal to the value of Maxlen;
o Minlenの値はMaxlenの値以下でなければなりません。
o the value of Route Type MUST be 0 (i.e., RESERVED); and
o Route Typeの値は0でなければなりません（つまり、予約済み）。そして
o the Host Address MUST contain exactly 128 bits.
o ホストアドレスは正確に128ビットを含まなければなりません。
If the ROUTE-REFRESH AFI is equal to L2VPN, the value of Route Type MUST be one of the following values taken from the IANA EVPN Registry [IANA.EVPN]:
ROUTE-REFRESH AFIがL2VPNと等しい場合、ルートタイプの値は、IANA EVPNレジストリ[IANA.EVPN]から取得した次の値のいずれかである必要があります。
o 1 - Ethernet Autodiscovery Route
o 1-イーサネット自動検出ルート
o 2 - MAC/IP Advertisement Route
o 2-MAC / IPアドバタイズメントルート
o 3 - Inclusive Multicast Route
o 3-包括的なマルチキャストルート
o 4 - Ethernet Segment
o 4-イーサネットセグメント
If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route Type is equal to Ethernet Autodiscovery Route, Inclusive Multicast Route, or Ethernet Segment,
ROUTE-REFRESH AFIがL2VPNに等しく、ルートタイプの値がイーサネット自動検出ルート、包括的マルチキャストルート、またはイーサネットセグメントに等しい場合、
o the value of Minlen MUST be equal to 0;
o Minlenの値は0でなければなりません。
o the value of Maxlen MUST be equal to 0; and
o Maxlenの値は0でなければなりません。そして
o the Host Address MUST be absent (i.e., contain 0 bits).
o ホストアドレスは存在しない必要があります（つまり、0ビットを含む）。
If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route Type is equal to MAC/IP Advertisement Route,
ROUTE-REFRESH AFIがL2VPNに等しく、ルートタイプの値がMAC / IPアドバタイズメントルートに等しい場合、
o the value of Minlen MUST be less than or equal to 48;
o Minlenの値は48以下でなければなりません。
o the value of Maxlen MUST be less than or equal to 48;
o Maxlenの値は48以下でなければなりません。
o the value of Minlen MUST be less than or equal to the value of Maxlen; and
o Minlenの値はMaxlenの値以下でなければなりません。そして
o the Host Address MUST contain exactly 48 bits.
o ホストアドレスは正確に48ビットを含まなければなりません。
According to [RFC4271], every BGP speaker maintains a single Loc-RIB. For each of its peers, the BGP speaker also maintains an Outbound Filter and an Adj-RIB-Out. The Outbound Filter defines policy that determines which Loc-RIB entries are processed into the corresponding Adj-RIB-Out. Mechanisms such as RT-Constrain [RFC4684] and ORF [RFC5291] enable a router's peer to influence the Outbound Filter. Therefore, the Outbound Filter for a given peer is constructed using a combination of the locally configured policy and the information received via RT-Constrain and ORF from the peer.
[RFC4271]によれば、すべてのBGPスピーカーは単一のLoc-RIBを維持します。ピアごとに、BGPスピーカーは送信フィルターとAdj-RIB-Outも維持します。送信フィルターは、対応するAdj-RIB-Outに処理されるLoc-RIBエントリを決定するポリシーを定義します。 RT制約[RFC4684]やORF [RFC5291]などのメカニズムにより、ルーターのピアがアウトバウンドフィルターに影響を与えることができます。したがって、特定のピアの送信フィルターは、ローカルに構成されたポリシーと、RT-ConstrainおよびORFを介してピアから受信した情報の組み合わせを使用して構築されます。
Using this model, we can describe the operations of CP-ORF as follows:
このモデルを使用して、CP-ORFの操作を次のように説明できます。
When a BGP speaker receives a ROUTE-REFRESH message that contains a CP-ORF and that ROUTE-REFRESH message violates any of the encoding rules specified in Section 2, the BGP speaker MUST ignore the entire ROUTE-REFRESH message. It SHOULD also log the event. However, an implementation MAY apply logging thresholds to avoid excessive messaging or log file overflow.
BGPスピーカーがCP-ORFを含むROUTE-REFRESHメッセージを受信し、そのROUTE-REFRESHメッセージがセクション2で指定されたエンコーディングルールのいずれかに違反している場合、BGPスピーカーはROUTE-REFRESHメッセージ全体を無視する必要があります。また、イベントをログに記録する必要があります。ただし、過剰なメッセージングやログファイルのオーバーフローを回避するために、実装はロギングしきい値を適用してもよい（MAY）。
Otherwise, the BGP speaker processes each CP-ORF entry as indicated by the Action field. If the Action is equal to ADD, the BGP speaker adds the CP-ORF entry to the Outbound Filter associated with the peer in the position specified by the Sequence field. If the Action is equal to REMOVE, the BGP speaker removes the CP-ORF entry from the Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP speaker removes all CP-ORF entries from the Outbound Filter.
それ以外の場合、BGPスピーカーは、アクションフィールドで示されるように各CP-ORFエントリを処理します。アクションがADDと等しい場合、BGPスピーカーは、シーケンスフィールドで指定された位置にあるピアに関連付けられた送信フィルターにCP-ORFエントリを追加します。アクションがREMOVEと等しい場合、BGPスピーカーはアウトバウンドフィルターからCP-ORFエントリを削除します。アクションがREMOVE-ALLと等しい場合、BGPスピーカーはすべてのCP-ORFエントリをアウトバウンドフィルターから削除します。
Whenever the BGP speaker applies an Outbound Filter to a route contained in its Loc-RIB, it evaluates the route in terms of the CP-ORF entries first. It then evaluates the route in terms of the remaining non-CP-ORF entries. The rules for the former are described below. The rules for the latter are outside the scope of this document.
BGPスピーカーがLoc-RIBに含まれるルートにアウトバウンドフィルターを適用するときは常に、最初にCP-ORFエントリに関してルートを評価します。次に、残りの非CP-ORFエントリに関してルートを評価します。前者のルールを以下に示します。後者のルールは、このドキュメントの範囲外です。
The following route types can match a CP-ORF:
次のルートタイプはCP-ORFと一致できます。
o IPv4-VPN
o IPv4-VPN
o IPv6-VPN
o IPv6-VPN
o L2VPN
o L2VPN
In order for an IPv4-VPN route or IPv6-VPN route to match a CP-ORF, all of the following conditions MUST be true:
IPv4-VPNルートまたはIPv6-VPNルートがCP-ORFと一致するためには、次の条件がすべて満たされている必要があります。
o the route carries an RT whose value is the same as the CP-ORF VPN Route Target;
o ルートは、値がCP-ORF VPNルートターゲットと同じであるRTを伝送します。
o the route prefix length is greater than or equal to the CP-ORF Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o ルートプレフィックスの長さがCP-ORF Minlenに64を加えた値（つまり、VPNルート識別子の長さ）以上である。
o the route prefix length is less than or equal to the CP-ORF Maxlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o ルートプレフィックスの長さがCP-ORF Maxlenに64を足したもの（つまり、VPNルート識別子の長さ）以下である。
o ignoring the Route Distinguisher, the leading bits of the route prefix are identical to the leading bits of the CP-ORF Host Address, and CP-ORF Minlen defines the number of bits that must be identical; and
o ルート識別子を無視すると、ルートプレフィックスの先頭ビットはCP-ORFホストアドレスの先頭ビットと同一であり、CP-ORF Minlenは同一でなければならないビット数を定義します。そして
o Loc-RIB does not contain a more specific route that also satisfies all of the above listed conditions.
o Loc-RIBには、上記のすべての条件を満たす、より具体的なルートは含まれていません。
The BGP speaker ignores Route Distinguishers when determining whether a prefix matches a host address. For example, assume that a CP-ORF carries the following information:
BGPスピーカーは、プレフィックスがホストアドレスと一致するかどうかを判断するときに、ルート識別子を無視します。たとえば、CP-ORFに次の情報が含まれているとします。
o Minlen equal to 1
o Minlen = 1
o Maxlen equal to 32
o Maxlenは32に等しい
o Host Address equal to 192.0.2.1
o 192.0.2.1に等しいホストアドレス
Assume also that Loc-RIB contains routes for the following IPv4-VPN prefixes and that all of these routes carry an RT whose value is the same as the CP-ORF VPN Route Target:
また、Loc-RIBには次のIPv4-VPNプレフィックスのルートが含まれ、これらのルートはすべて、値がCP-ORF VPNルートターゲットと同じであるRTを伝送すると仮定します。
o 1:0.0.0.0/64.
o １：０。０。０。０／６４。
o 2:192.0.2.0/88
o ２：１９２。０。２。０／８８
o 3:192.0.2.0/89 Only the prefix 3:192.0.2.0/89 matches the CP-ORF. The prefix 1:0.0.0.0/64 does not match, because its length (64) is less than the CP-ORF Minlen (1) plus the length of an L3VPN Route Distinguisher (64). If Loc-RIB did not contain the prefix 3:192.0.2.0/89, 2:192.0.2.0/88 would match the CP-ORF. However, because Loc-RIB also contains a more specific covering route (3:192.0.2.0/89), 2:192.0.2.0/88 does not match. Only 3:192.0.2.0/89 satisfies all of the above listed match criteria. Note that the matching algorithm ignored Route Distinguishers.
o 3：192.0.2.0/89プレフィックス3：192.0.2.0/89のみがCP-ORFと一致します。プレフィックス1：0.0.0.0/64は一致しません。その長さ（64）は、CP-ORF Minlen（1）とL3VPNルート識別子（64）の長さの合計よりも短いためです。 Loc-RIBにプレフィックス3：192.0.2.0/89が含まれていない場合、2：192.0.2.0/88はCP-ORFと一致します。ただし、Loc-RIBにはより具体的なカバールート（3：192.0.2.0/89）も含まれているため、2：192.0.2.0/88は一致しません。上記のすべての一致基準を満たすのは、3：192.0.2.0/89だけです。マッチングアルゴリズムはルート識別子を無視したことに注意してください。
In order for an EVPN route to match a CP-ORF, all of the following conditions MUST be true:
EVPNルートがCP-ORFと一致するためには、次の条件がすべて満たされている必要があります。
o the EVPN route type is equal to the CP-ORF Route Type; and
o EVPNルートタイプはCP-ORFルートタイプと同じです。そして
o the route carries an RT whose value is equal to the CP-ORF VPN Route Target.
o ルートは、値がCP-ORF VPNルートターゲットと等しいRTを伝送します。
In addition, if the CP-ORF Route Type is equal to MAC/IP Advertisement Route, the following conditions also MUST be true:
さらに、CP-ORFルートタイプがMAC / IPアドバタイズメントルートと等しい場合、次の条件も真でなければなりません：
o the EVPN Route MAC Address Length is greater than or equal to the CP-ORF Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o EVPNルートのMACアドレスの長さは、CP-ORF Minlenに64を加えた値（つまり、VPNルート識別子の長さ）以上です。
o the EVPN Route MAC Address Length is less than or equal to the CP-ORF Maxlen plus 64 (i.e., the length of a VPN Route Distinguisher); and
o EVPNルートMACアドレス長は、CP-ORF Maxlenに64を足したもの（つまり、VPNルート識別子の長さ）以下です。そして
o ignoring the Route Distinguisher, the leading bits of the EVPN Route MAC Address are identical to the leading bits of the CP-ORF Host Address. CP-ORF Minlen defines the number of bits that must be identical.
o ルート識別子を無視すると、EVPNルートMACアドレスのリーディングビットは、CP-ORFホストアドレスのリーディングビットと同一です。 CP-ORF Minlenは、同一でなければならないビット数を定義します。
If a route matches the selection criteria of a CP-ORF entry and it does not violate any subsequent rule specified by the Outbound Filter (e.g., rules that reflect local policy or rules that are due to RT-Constrains), the BGP speaker places the route into the Adj-RIB-Out. In Adj-RIB-Out, the BGP speaker adds the CP-ORF Import Route Target to the list of RTs that the route already carries. The BGP speaker also adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF (0x03). As a result of being placed in Adj-RIB-Out, the route is advertised to the peer associated with the Adj-RIB-Out.
ルートがCP-ORFエントリの選択基準に一致し、アウトバウンドフィルターによって指定された後続のルール（たとえば、ローカルポリシーを反映するルールまたはRT制約によるルール）に違反していない場合、BGPスピーカーはAdj-RIB-Outにルーティングします。 Adj-RIB-Outでは、BGPスピーカーが、ルートが既に実行しているRTのリストにCP-ORFインポートルートターゲットを追加します。 BGPスピーカーは、サブタイプがCP-ORF（0x03）に等しいTransitive Opaque Extended Community [RFC4360]も追加します。 Adj-RIB-Outに配置された結果、ルートはAdj-RIB-Outに関連付けられたピアにアドバタイズされます。
Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause a route that has previously been installed in a particular Adj-RIB-Out to be excluded from that Adj-RIB-Out. In this case, as specified in [RFC4271], "the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message".
REMOVEまたはREMOVE-ALLアクションでCP-ORFエントリを受信すると、特定のAdj-RIB-Outに以前にインストールされたルートがそのAdj-RIB-Outから除外される場合があります。この場合、[RFC4271]で指定されているように、「そのAdj-RIB-Outで以前にアドバタイズされたルートは、UPDATEメッセージを使用してサービスから撤回する必要があります」。
RFC 5291 states that a BGP speaker should respond to a ROUTE REFRESH message as follows:
RFC 5291では、BGPスピーカーはROUTE REFRESHメッセージに次のように応答する必要があると述べています。
If the When-to-refresh indicates IMMEDIATE, then after processing all the ORF entries carried in the message the speaker re-advertises to the peer routes from the Adj-RIB-Out associated with the peer that have the same AFI/SAFI as what is carried in the message, and taking into account all the ORF entries for that AFI/SAFI received from the peer. The speaker MUST re-advertise all the routes that have been affected by the ORF entries carried in the message, but MAY also re-advertise the routes that have not been affected by the ORF entries carried in the message.
When-to-refreshがIMMEDIATEを示している場合、メッセージに含まれるすべてのORFエントリを処理した後、スピーカーは、ピアと関連付けられているAdj-RIB-Outからピアルートに再アドバタイズします。メッセージで伝達され、ピアから受信したそのAFI / SAFIのすべてのORFエントリを考慮に入れます。スピーカーは、メッセージで運ばれたORFエントリによって影響を受けたすべてのルートを再アドバタイズしなければなりません（MUST）が、メッセージで運ばれたORFエントリによって影響を受けなかったルートも再アドバタイズできます（MAY）。
When the ROUTE-REFRESH message includes only CP-ORF entries, the BGP speaker MUST re-advertise routes that have been affected by these CP-ORF entries. It is RECOMMENDED not to re-advertise the routes that have not been affected by the CP-ORF entries.
ROUTE-REFRESHメッセージにCP-ORFエントリのみが含まれる場合、BGPスピーカーはこれらのCP-ORFエントリの影響を受けたルートを再アドバタイズする必要があります。 CP-ORFエントリの影響を受けていないルートを再アドバタイズしないことをお勧めします。
When the ROUTE-REFRESH message includes one or more CP-ORF entries and one or more ORF entries of a different type, the behavior remains unchanged from that described in RFC 5291.
ROUTE-REFRESHメッセージに1つまたは複数のCP-ORFエントリと異なるタイプの1つまたは複数のORFエントリが含まれている場合、動作はRFC 5291で説明されているものから変更されません。
In a Virtual Hub-and-Spoke environment, VPN sites are attached to PE routers. For a given VPN, a PE router acts in exactly one of the following roles:
仮想HUB＆スポーク環境では、VPNサイトはPEルーターに接続されます。特定のVPNの場合、PEルーターは次のいずれかの役割を果たします。
o as a V-hub
o Vハブとして
o as a V-spoke
o Vスポークとして
o as neither a V-hub nor a V-spoke
o VハブでもVスポークでもない
To illustrate CP-ORF operation in conjunction with Virtual Hub-and-Spoke, assume the following:
仮想HUBアンドスポークと組み合わせたCP-ORFの動作を説明するために、以下を想定します。
o One of the sites in a particular VPN, RED-VPN, is connected to a PE that acts as neither a V-hub nor a V-spoke for RED-VPN. We refer to this PE as PE1.
o 特定のVPNのサイトの1つであるRED-VPNは、RED-VPNのVハブでもVスポークでもないPEに接続されています。このPEをPE1と呼びます。
o Another site in RED-VPN is connected to another PE, and that PE acts as a V-hub for RED-VPN. We refer to this PE as V-hub1.
o RED-VPNの別のサイトは別のPEに接続され、そのPEはRED-VPNのVハブとして機能します。このPEをV-hub1と呼びます。
o Yet another site in RED-VPN is connected to another PE, and that PE acts as a V-spoke for RED-VPN. We refer to this PE as V-spoke1.
o さらに、RED-VPNの別のサイトは別のPEに接続され、そのPEはRED-VPNのVスポークとして機能します。このPEをV-spoke1と呼びます。
All of these PEs advertise RED-VPN routes to a Route Reflector (RR). They mark these routes with an RT, which we will call RT-RED. In particular, PE1 advertises a RED-VPN route to a prefix that we will call P. P covers a host address that we will call H.
これらすべてのPEは、RED-VPNルートをRoute Reflector（RR）にアドバタイズします。これらのルートはRTでマークされます。これをRT-REDと呼びます。特に、PE1は、RED-VPNルートを、Pと呼ぶプレフィックスにアドバタイズします。Pは、Hと呼ぶホストアドレスをカバーします。
For the purpose of illustration, also assume that the PEs and the RRs use RT-Constrain [RFC4684].
説明のために、PEとRRがRT-Constrain [RFC4684]を使用していると仮定します。
V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN-IP default route for the RED-VPN to the RR, carrying the route target RT-RED-FROM-HUB1.
V-hub1はRED-VPNを提供します。したがって、V-hub1はRED-VPNのVPN-IPデフォルトルートをRRにアドバタイズし、ルートターゲットRT-RED-FROM-HUB1を伝送します。
V-spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760]. Upon establishment of the BGP session, the RR does not advertise any routes to V-spoke1. The RR will not advertise any routes until it receives either a ROUTE-REFRESH message or a BGP UPDATE message containing a Route Target Membership Network Layering Reachability Information (NLRI) [RFC4684].
V-spoke1はRRとのBGPセッションを確立し、CP-ORF機能とマルチプロトコル拡張機能[RFC4760]をネゴシエートします。 BGPセッションの確立時に、RRはルートをV-spoke1にアドバタイズしません。ルートターゲットメンバーシップネットワークレイヤリング到達可能性情報（NLRI）[RFC4684]を含むROUTE-REFRESHメッセージまたはBGP UPDATEメッセージを受信するまで、RRはルートをアドバタイズしません。
Immediately after the BGP session is established, V-spoke1 sends the RR a BGP UPDATE message containing a Route Target Membership NLRI. The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its RT. In response to the BGP-UPDATE message, the RR advertises the VPN IP default route for the RED-VPN to V-spoke1. This route carries the route target RT-RED-FROM-HUB1. V-spoke1 subjects this route to its import policy and accepts it because it carries the route target RT-RED-FROM-HUB1.
BGPセッションが確立された直後に、V-spoke1はRRにルートターゲットメンバーシップNLRIを含むBGP UPDATEメッセージを送信します。ルートターゲットメンバーシップNLRIは、RT-RED-FROM-HUB1をRTとして指定します。 BGP-UPDATEメッセージに応答して、RRはRED-VPNのVPN IPデフォルトルートをV-spoke1にアドバタイズします。このルートは、ルートターゲットRT-RED-FROM-HUB1を伝送します。 V-spoke1はこのルートにインポートポリシーを適用し、ルートターゲットRT-RED-FROM-HUB1を伝送するため、それを受け入れます。
Now, V-spoke1 begins normal operation, sending all of its RED-VPN traffic through V-hub1. At some point, V-spoke1 determines that it might benefit from a more direct route to H. (Note that criteria by which V-spoke1 determines that it needs a more direct route to H are beyond the scope of this document.) In order to discover a more direct route, V-spoke1 assigns a unique numeric identifier to H. V-spoke1 then sends a ROUTE-REFRESH message to the RR, which contains the following information:
これで、V-spoke1は通常の動作を開始し、RED-VPNトラフィックのすべてをV-hub1経由で送信します。ある時点で、V-spoke1は、Hへのより直接的なルートから利益を得る可能性があると判断します（Hへのより直接的なルートが必要であるとV-spoke1が判断する基準は、このドキュメントの範囲外であることに注意してください）。より直接的なルートを発見するために、V-spoke1は一意の数値識別子をHに割り当てます。次に、V-spoke1はROUTE-REFRESHメッセージをRRに送信します。これには次の情報が含まれます。
o AFI is equal to IPv4 or IPv6, as appropriate
o AFIは、必要に応じてIPv4またはIPv6と同等です
o SAFI is equal to "MPLS-labeled VPN address"
o SAFIは「MPLSラベル付きVPNアドレス」に等しい
o When-to-refresh is equal to IMMEDIATE
o When-to-refreshがIMMEDIATEに等しい
o Action is equal to ADD
o アクションはADDと同じです
o Match is equal to PERMIT
o 一致はPERMITに等しい
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to the identifier associated with H
o CP-ORFシーケンスはHに関連付けられた識別子に等しい
o CP-ORF Minlen is equal to 1
o CP-ORF Minlenは1に等しい
o CP-ORF Maxlen is equal to 32 or 128, as appropriate
o CP-ORF Maxlenは、必要に応じて32または128に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1
o CP-ORFインポートルートターゲットがRT-RED-FROM-HUB1と等しい
o CP-ORF Route Type is equal to 0 (i.e., undefined)
o CP-ORFルートタイプが0に等しい（つまり、未定義）
o CP-ORF Host Address is equal to H
o CP-ORFホストアドレスがHに等しい
Upon receipt of the ROUTE-REFRESH message, the RR MUST ensure that it carries all routes belonging to the RED-VPN. In at least one special case, where all of the RR clients are V-spokes and none of the RR clients are V-hubs, the RR will lack some or all of the required RED-VPN routes. So, the RR sends a BGP UPDATE message containing a Route Target Membership NLRI for VPN-RED to all of its peers. This causes the peers to advertise VPN-RED routes to the RR if they have not done so already.
ROUTE-REFRESHメッセージを受信すると、RRは、RED-VPNに属するすべてのルートを伝送することを確認する必要があります。少なくとも1つの特殊なケースでは、すべてのRRクライアントがVスポークであり、どのRRクライアントもVハブではない場合、RRには必要なRED-VPNルートの一部またはすべてが不足します。したがって、RRはすべてのピアに、VPN-REDのルートターゲットメンバーシップNLRIを含むBGP UPDATEメッセージを送信します。これにより、ピアはVPN-REDルートをRRにまだアドバタイズしていない場合にアドバタイズします。
Next, the RR adds the received CP-ORF to the Outbound Filter associated with V-spoke1. Using the procedures in Section 3, the RR determines whether any of the routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes satisfy the match criteria, they are added to the Adj-RIB-Out associated with V-spoke1. In Adj-RIB-Out, the RR adds RT-RED-FROM-HUB1 to the list of RTs that the route already carries. The RR also adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF. Finally, RR advertises the newly added routes to V-spoke1. In this example, the RR advertises P to V-spoke1 with a next-hop of PE1.
次に、RRは受信したCP-ORFをV-spoke1に関連付けられた送信フィルターに追加します。セクション3の手順を使用して、RRは、Loc-RIB内のルートのいずれかが、新しく更新されたアウトバウンドフィルターの選択基準を満たすかどうかを判断します。いずれかのルートが一致条件を満たす場合、それらはV-spoke1に関連付けられたAdj-RIB-Outに追加されます。 Adj-RIB-Outでは、RRはRT-RED-FROM-HUB1を、ルートが既に実行しているRTのリストに追加します。 RRは、CP-ORFに等しいサブタイプの推移的不透明拡張コミュニティ[RFC4360]も追加します。最後に、RRは新しく追加されたルートをV-spoke1にアドバタイズします。この例では、RRはP1のネクストホップでPをV-spoke1にアドバタイズします。
V-spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED-FROM-HUB1.
V-spoke1は、アドバタイズされたルートにインポートポリシーを適用し、ルートターゲットRT-RED-FROM-HUB1を伝送するため、それらを受け入れます。
V-spoke1 may repeat this process whenever it discovers another flow that might benefit from a more direct route to its destination.
V-spoke1は、宛先へのより直接的なルートの恩恵を受ける可能性のある別のフローを検出するたびに、このプロセスを繰り返す場合があります。
When applying Multicast VPN [RFC6513] [RFC6514] procedures, routes bearing a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF MUST NOT be used to determine Eligible Upstream Multicast Hops (UMH).
マルチキャストVPN [RFC6513] [RFC6514]手順を適用する場合、サブタイプがCP-ORFである推移的不透明拡張コミュニティ[RFC4360]を持つルートを使用して、適格なアップストリームマルチキャストホップ（UMH）を決定することはできません。
In an EVPN environment, Customer Edge (CE) devices are attached to PE routers. A CE can be a host, a router, or a switch. For a given EVI, a PE router acts in exactly one of the following roles:
EVPN環境では、カスタマーエッジ（CE）デバイスはPEルーターに接続されます。 CEは、ホスト、ルーター、またはスイッチにすることができます。特定のEVIの場合、PEルーターは次のいずれかの役割を果たします。
o as a DMG
o DMGとして
o as a Spoke
o スポークとして
o as neither a DMG nor a Spoke
o DMGでもスポークでもない
To illustrate CP-ORF operation in the EVPN environment, assume the following:
EVPN環境でのCP-ORF動作を説明するために、以下を想定します。
o A CE device in a particular EVI, RED-EVI, is connected to a PE that acts as neither a DMG nor a Spoke for RED-EVI. We refer to this PE as PE1.
o 特定のEVIであるRED-EVIのCEデバイスは、RED-EVIのDMGでもスポークでもないPEに接続されています。このPEをPE1と呼びます。
o Another CE device in RED-EVI is connected to another PE, and that PE acts as a DMG for RED-EVI. We refer to this PE as DMG1.
o RED-EVIの別のCEデバイスは別のPEに接続され、そのPEはRED-EVIのDMGとして機能します。このPEをDMG1と呼びます。
o Yet another CE device in RED-EVI is connected to another PE, and that PE acts as a Spoke for RED-EVI. We refer to this PE as Spoke1.
o さらに、RED-EVIの別のCEデバイスは別のPEに接続され、そのPEはRED-EVIのスポークとして機能します。このPEをSpoke1と呼びます。
All of these PEs advertise RED-EVI routes to a RR. They mark these routes with an RT, which we will call RT-RED. In particular, PE1 advertises a RED-EVI route to a MAC Address that we will call M.
これらのPEはすべて、RED-EVIルートをRRにアドバタイズします。これらのルートはRTでマークされます。これをRT-REDと呼びます。特に、PE1は、RED-EVIルートを、Mと呼ぶMACアドレスにアドバタイズします。
The RED-EVI VPN Routing and Forwarding tables (VRFs) on all of these PEs are provisioned to import EVPN routes that carry RT-RED.
これらすべてのPEのRED-EVI VPNルーティングおよび転送テーブル（VRF）は、RT-REDを伝送するEVPNルートをインポートするためにプロビジョニングされます。
Since DMG1 acts as a DMG for RED-EVI, DMG1 advertises a UMR for the RED-EVI to the RR, carrying the route target RT-RED. The UMR is characterized as follows:
DMG1はRED-EVIのDMGとして機能するため、DMG1はRED-EVIのUMRをRRにアドバタイズし、ルートターゲットRT-REDを伝送します。 UMRの特徴は次のとおりです。
o EVPN Route Type is equal to MAC/IP Advertisement Route
o EVPNルートタイプがMAC / IPアドバタイズメントルートと等しい
o MAC address length is equal to 0
o MACアドレスの長さが0に等しい
o IP address length is equal to 0
o IPアドレスの長さが0に等しい
Spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760]. Upon establishment of the BGP session, the RR does not advertise any routes to Spoke1. The RR will not advertise any routes until it receives a ROUTE-REFRESH message.
Spoke1はRRとのBGPセッションを確立し、CP-ORF機能とマルチプロトコル拡張機能[RFC4760]をネゴシエートします。 BGPセッションの確立時に、RRはルートをSpoke1にアドバタイズしません。 RRは、ROUTE-REFRESHメッセージを受信するまで、ルートをアドバタイズしません。
Immediately after the BGP session is established, Spoke1 sends the RR a ROUTE REFRESH message containing the following information:
BGPセッションが確立された直後に、Spoke1はRRに次の情報を含むROUTE REFRESHメッセージを送信します。
o AFI is equal to L2VPN
o AFIはL2VPNと同じです
o SAFI is equal to BGP EVPN
o SAFIはBGP EVPNと同等
o When-to-refresh is equal to IMMEDIATE
o When-to-refreshがIMMEDIATEに等しい
o Action is equal to ADD
o アクションはADDと同じです
o Match is equal to PERMIT
o 一致はPERMITに等しい
The ROUTE REFRESH message also contains four ORF entries. The first ORF entry contains the following information:
ROUTE REFRESHメッセージには、4つのORFエントリも含まれています。最初のORFエントリには、次の情報が含まれています。
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to 1
o CP-ORFシーケンスが1に等しい
o CP-ORF Minlen is equal to 0
o CP-ORF Minlenは0です
o CP-ORF Maxlen is equal to 0
o CP-ORF Maxlenが0に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORFインポートルートターゲットがRT-REDに等しい
o CP-ORF Route Type is equal to 1 (Ethernet Autodiscovery Route) The second ORF entry contains the following information:
o CP-ORFルートタイプが1に等しい（イーサネット自動検出ルート）2番目のORFエントリには、次の情報が含まれています。
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to 2
o CP-ORFシーケンスは2に等しい
o CP-ORF Minlen is equal to 0
o CP-ORF Minlenは0です
o CP-ORF Maxlen is equal to 0
o CP-ORF Maxlenが0に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORFインポートルートターゲットがRT-REDに等しい
o CP-ORF Route Type is equal to 2 (MAC/IP Advertisement Route)
o CP-ORFルートタイプは2に等しい（MAC / IPアドバタイズメントルート）
The third ORF entry contains the following information:
3番目のORFエントリには、次の情報が含まれています。
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to 3
o CP-ORFシーケンスが3に等しい
o CP-ORF Minlen is equal to 0
o CP-ORF Minlenは0です
o CP-ORF Maxlen is equal to 0
o CP-ORF Maxlenが0に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORFインポートルートターゲットがRT-REDに等しい
o CP-ORF Route Type is equal to 3 (Inclusive Multicast Route)
o CP-ORFルートタイプは3（包括的マルチキャストルート）に等しい
The fourth ORF entry contains the following information:
4番目のORFエントリには、次の情報が含まれています。
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to 4
o CP-ORFシーケンスは4に等しい
o CP-ORF Minlen is equal to 0
o CP-ORF Minlenは0です
o CP-ORF Maxlen is equal to 0
o CP-ORF Maxlenが0に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORFインポートルートターゲットがRT-REDに等しい
o CP-ORF Route Type is equal to 4 (Ethernet Segment) In response to the ROUTE REFRESH message, the RR advertises the following to V-spoke1:
o CP-ORFルートタイプが4（イーサネットセグメント）に等しいROUTE REFRESHメッセージに応答して、RRは次のものをV-spoke1に通知します。
o All Ethernet Autodiscovery Routes belonging to RED-EVI
o RED-EVIに属するすべてのイーサネット自動検出ルート
o A UMR advertised by DMG1 and belonging to RED-EVI
o DMG1によってアドバタイズされ、RED-EVIに属するUMR
o All Inclusive Multicast Routes belonging to RED-EVI
o RED-EVIに属するオールインクルーシブマルチキャストルート
o All Ethernet Segment Routes belonging to RED-EVI
o RED-EVIに属するすべてのイーサネットセグメントルート
All of these routes carry the route target RT-RED. Spoke1 subjects these routes to its import policy and accepts them because they carry the route target RT-RED.
これらのルートはすべて、ルートターゲットRT-REDを伝送します。 Spoke1は、これらのルートにインポートポリシーを適用し、ルートターゲットRT-REDを伝送するため、それらを受け入れます。
Now, Spoke1 begins normal operation, sending all of its RED-VPN traffic through DMG1. At some point, Spoke1 determines that it might benefit from a more direct route to M. (Note that criteria by which Spoke1 determines that it needs a more direct route to M are beyond the scope of this document.)
これで、Spoke1は通常の動作を開始し、RED-VPNトラフィックをすべてDMG1経由で送信します。ある時点で、Spoke1は、Mへのより直接的なルートの恩恵を受ける可能性があると判断します（Mへのより直接的なルートが必要であるとSpoke1が判断する基準は、このドキュメントの範囲外です）。
In order to discover a more direct route, Spoke1 assigns a unique numeric identifier to M. V-spoke1 then sends a ROUTE-REFRESH message to the RR, containing the following information:
より直接的なルートを発見するために、Spoke1は一意の数値識別子をMに割り当てます。次に、V-spoke1は、次の情報を含むROUTE-REFRESHメッセージをRRに送信します。
o AFI is equal to L2VPN
o AFIはL2VPNと同じです
o SAFI is equal to BGP EVPN
o SAFIはBGP EVPNと同等
o When-to-refresh is equal to IMMEDIATE
o When-to-refreshがIMMEDIATEに等しい
o Action is equal to ADD
o アクションはADDと同じです
o Match is equal to PERMIT
o 一致はPERMITに等しい
o ORF Type is equal to CP-ORF
o ORFタイプはCP-ORFと同じです
o CP-ORF Sequence is equal to the identifier associated with M
o CP-ORFシーケンスはMに関連付けられた識別子に等しい
o CP-ORF Minlen is equal to 1
o CP-ORF Minlenは1に等しい
o CP-ORF Maxlen is equal to 48
o CP-ORF Maxlenは48に等しい
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPNルートターゲットがRT-REDと等しい
o CP-ORF Import Route Target is equal to RT-RED o CP-ORF Route Type is equal to 2 (i.e., MAC/IP Advertisement Route)
o CP-ORFインポートルートターゲットがRT-REDに等しいo CP-ORFルートタイプが2に等しい（つまり、MAC / IPアドバタイズメントルート）
o CP-ORF Host Address is equal to M
o CP-ORFホストアドレスがMに等しい
Next, the RR adds the received CP-ORF to the Outbound Filter associated with Spoke1. Using the procedures in Section 3, the RR determines whether any of the routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes satisfy the match criteria, they are added to the Adj-RIB-Out associated with Spoke1. The RR adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF. Note that as these routes are added to the Adj-RIB-Out, the RR does not change the list of RTs that the route already carries. Finally, RR advertises the newly added routes to V-spoke1. In this example, the RR advertises M to V-spoke1 with a next-hop of PE1.
次に、RRは受信したCP-ORFをSpoke1に関連付けられた送信フィルターに追加します。セクション3の手順を使用して、RRは、Loc-RIB内のルートのいずれかが、新しく更新されたアウトバウンドフィルターの選択基準を満たすかどうかを判断します。いずれかのルートが一致条件を満たす場合、それらはSpoke1に関連付けられたAdj-RIB-Outに追加されます。 RRは、CP-ORFに等しいサブタイプの推移的不透明拡張コミュニティ[RFC4360]を追加します。これらのルートはAdj-RIB-Outに追加されるので、RRはルートがすでに持っているRTのリストを変更しないことに注意してください。最後に、RRは新しく追加されたルートをV-spoke1にアドバタイズします。この例では、RRはMをネクストホップPE1でV-spoke1にアドバタイズします。
Spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED.
Spoke1は、アドバタイズされたルートにインポートポリシーを適用し、ルートターゲットRT-REDを伝送するため、それらを受け入れます。
Spoke1 may repeat this process whenever it discovers another flow that might benefit from a more direct route to its destination.
Spoke1は、宛先へのより直接的なルートの恩恵を受ける可能性のある別のフローを検出するたびに、このプロセスを繰り返す場合があります。
Note that, in general, an EVI may have more than one DMG, in which case each spoke would receive a UMR from each of them. The spoke should follow its local route selection procedures to select one of them as the "best" and use the selected one.
一般に、EVIには複数のDMGがある場合があることに注意してください。その場合、各スポークはそれぞれからUMRを受け取ります。スポークはローカルルート選択手順に従って、そのうちの1つを「最良」として選択し、選択したものを使用する必要があります。
Each CP-ORF consumes memory and compute resources on the device that supports it. Therefore, in order to obtain optimal performance, BGP speakers periodically evaluate all CP-ORFs that they have originated and remove unneeded CP-ORFs. The criteria by which a BGP speaker identifies unneeded CP-ORF entries is a matter of local policy and is beyond the scope of this document.
各CP-ORFは、それをサポートするデバイスのメモリと計算リソースを消費します。したがって、最適なパフォーマンスを得るために、BGPスピーカーは定期的に発生したすべてのCP-ORFを評価し、不要なCP-ORFを削除します。 BGPスピーカーが不要なCP-ORFエントリを識別する基準はローカルポリシーの問題であり、このドキュメントの範囲外です。
This memo uses code points from the First Come First Served [RFC5226] range of the following registries:
このメモは、次のレジストリの先着順[RFC5226]範囲のコードポイントを使用しています。
+------------------------------------------------+---------------+
| Registry | Code Point |
+------------------------------------------------+---------------+
| BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) |
| Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) |
+------------------------------------------------+---------------+
IANA has updated the above-mentioned registry entries so that they reference this memo.
IANAは、このメモを参照するように、上記のレジストリエントリを更新しました。
Each CP-ORF consumes memory and compute resources on the device that supports it. Therefore, a device supporting CP-ORF takes the following steps to protect itself from oversubscription:
各CP-ORFは、それをサポートするデバイスのメモリと計算リソースを消費します。したがって、CP-ORFをサポートするデバイスは、次の手順を実行してオーバーサブスクリプションからデバイスを保護します。
o When negotiating the ORF capability, advertise willingness to receive the CP-ORF only to known, trusted Internal BGP (iBGP) peers. See Section 5 of RFC 5291 for negotiation details.
o ORF機能をネゴシエートするときは、CP-ORFを受信する意思を、信頼できる既知の内部BGP（iBGP）ピアにのみ通知します。交渉の詳細については、RFC 5291のセクション5をご覧ください。
o Enforce a per-peer limit on the number of CP-ORFs that can be installed at any given time. Ignore all requests to add CP-ORFs beyond that limit
o いつでもインストールできるCP-ORFの数にピアごとの制限を適用します。その制限を超えてCP-ORFを追加する要求をすべて無視します
Security considerations for BGP are presented in [RFC4271] while further security analysis of BGP is found in [RFC6952].
BGPのセキュリティに関する考慮事項は[RFC4271]に示され、BGPのセキュリティ分析は[RFC6952]にあります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月、<http：/ /www.rfc-editor.org/info/rfc4271>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、2006年2月、<http://www.rfc-editor.org/info/rfc4360>。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月、<http://www.rfc-editor.org/info/rfc4684>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月、<http://www.rfc-editor.org / info / rfc4760>。
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008, <http://www.rfc-editor.org/info/rfc5291>.
[RFC5291] Chen、E。およびY. Rekhter、「BGP-4のアウトバウンドルートフィルタリング機能」、RFC 5291、2008年8月、<http://www.rfc-editor.org/info/rfc5291>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNでのマルチキャスト」、RFC 6513、2012年2月、<http://www.rfc-editor.org/info/rfc6513>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、2012年2月、<http：// www .rfc-editor.org / info / rfc6514>。
[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, October 2013, <http://www.rfc-editor.org/info/rfc7024>.
[RFC7024] Jeng、H.、Uttaro、J.、Jalil、L.、Decraene、B.、Rekhter、Y。、およびR. Aggarwal、「BGP / MPLS VPNの仮想ハブアンドスポーク」、RFC 7024、 2013年10月、<http://www.rfc-editor.org/info/rfc7024>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A。、編、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J。、およびW. Henderickx、「BGP MPLSベースのイーサネットVPN」、 RFC 7432、2015年2月、<http://www.rfc-editor.org/info/rfc7432>。
[IANA.AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[IANA.AFI] IANA、 "Address Family Numbers"、<http://www.iana.org/assignments/address-family-numbers>。
[IANA.EVPN] IANA, "Ethernet VPN (EVPN)", <http://www.iana.org/assignments/evpn>.
[IANA.EVPN] IANA、「イーサネットVPN（EVPN）」、<http://www.iana.org/assignments/evpn>。
[IANA.SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <http://www.iana.org/assignments/safi-namespace>.
[IANA.SAFI] IANA、「Subsequent Address Family Identifiers（SAFI）Parameters」、<http://www.iana.org/assignments/safi-namespace>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、2006年2月、<http://www.rfc-editor.org/info/rfc4364>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの分析とルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによる問題」、RFC 6952、5月2013、<http://www.rfc-editor.org/info/rfc6952>。
Acknowledgements
謝辞
The authors wish to acknowledge Han Nguyen, James Uttaro, and Alvaro Retana for their comments and contributions.
著者は、コメントと寄稿に対して、Han Nguyen、James Uttaro、およびAlvaro Retanaに感謝します。
Contributors
貢献者
The following individuals contributed to the development of this document:
以下の個人がこのドキュメントの開発に貢献しました：
o Yakov Rekhter
o ヤコフ・レクター
o Xiaohu Xu
o ξアウトバックX U
Authors' Addresses
著者のアドレス
Huajin Jeng AT&T
Huajin Ms. AT＆T
EMail: hj2387@att.com
Luay Jalil Verizon
ルアイ・ジャリル・ベライゾン
EMail: luay.jalil@verizon.com
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20170 United States
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon、Virginia 20170アメリカ
EMail: rbonica@juniper.net
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, California 95134 United States
Keyur Patel Cisco Systems 170 W. Tasman Driveサンノゼ、カリフォルニア95134アメリカ合衆国
EMail: keyupate@cisco.com
Lucy Yong Huawei Technologies Austin, Texas United States
Lucy Yong hu Aテクノロジーのオースティン、テキサス州アメリカ合衆国
EMail: lucy.yong@huawei.com