[要約] RFC 7024は、BGP/MPLS VPNsにおける仮想ハブアンドスポークの実装に関するガイドラインです。このRFCの目的は、ネットワークエンジニアがBGP/MPLS VPNsで効果的な仮想ハブアンドスポークアーキテクチャを設計および展開するための手順を提供することです。
Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7024 J. Uttaro
Category: Standards Track AT&T
ISSN: 2070-1721 L. Jalil
Verizon
B. Decraene
Orange
Y. Rekhter
Juniper Networks
R. Aggarwal
Arktan
October 2013
Virtual Hub-and-Spoke in BGP/MPLS VPNs
BGP / MPLS VPNの仮想HUBアンドスポーク
Abstract
概要
With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
BGP / MPLSバーチャルプライベートネットワーク（VPN）では、特定のVPNのサイト間でAny-to-Any接続を提供するには、これらのサイトの1つ以上に接続されている各プロバイダーエッジ（PE）ルーターが、そのVPNのすべてのルートを保持する必要があります。このドキュメントで説明するアプローチにより、VPNサービスプロバイダーは、これらのすべてのルートを維持するためにこれらのルーターのサブセットのみを要求することにより、これらすべてのルートを維持する必要があるPEルーターの数を減らすことができます。
Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.
さらに、PEルータがVPN顧客のマルチキャストトラフィックを伝送するために入力レプリケーションを使用する場合、このドキュメントで説明されているアプローチは、特定の状況下で、入力レプリケーションに関連する帯域幅の非効率性を低減し、PEルータ間でレプリケーションの負荷を再分散します。
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/rfc7024.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7024で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. Overview ........................................................3
2. Specification of Requirements ...................................4
3. Routing Information Exchange ....................................5
4. Forwarding Considerations .......................................7
5. Internet Connectivity ...........................................9
6. Deployment Considerations ......................................12
7. Multicast Considerations .......................................13
7.1. Terminology ...............................................14
7.2. Eligible Upstream Multicast Hop (UMH) Routes ..............14
7.3. Originating VPN-IP Default Route by a V-Hub ...............14
7.4. Handling C-Multicast Routes ...............................15
7.5. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ........15
7.6. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Hub ..........16
7.7. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ..........17
7.8. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Hub ............17
7.8.1. Case 1 .............................................17
7.8.2. Case 2 .............................................18
7.9. Use of Ingress Replication with I-PMSI A-D Routes .........20
8. An Example of RT Provisioning ..................................21
8.1. Unicast Routing ...........................................21
8.2. Multicast Routing .........................................22
9. Further Refinements ............................................23
10. Security Considerations .......................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................24
With BGP/MPLS VPNs [RFC4364], providing any-to-any connectivity among sites of a given VPN is usually accomplished by requiring each Provider Edge (PE) router connected to one or more of these sites to hold all that VPN's routes. The approach described in this document allows the VPN service provider (SP) to reduce the number of PEs that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
BGP / MPLS VPN [RFC4364]を使用すると、特定のVPNのサイト間でAny-to-Any接続を提供するには、通常、これらのサイトの1つ以上に接続されている各プロバイダーエッジ（PE）ルーターがそのVPNのルートをすべて保持する必要があります。このドキュメントで説明するアプローチにより、VPNサービスプロバイダー（SP）は、これらのすべてのルートを維持するためにこれらのルーターのサブセットのみを要求することにより、これらすべてのルートを維持する必要があるPEの数を減らすことができます。
Consider a set of PEs that maintain VPN Routing and Forwarding tables (VRFs) of a given VPN. In the context of this VPN, we designate a subset of these PEs as "Virtual Spoke" PEs (or just Virtual Spokes), while some other (non-overlapping) subset of these PEs will be "Virtual Hub" PEs (or just Virtual Hubs). The rest of the PEs in the set will be "vanilla" PEs (PEs that implement the procedures described in [RFC4364] but that do not implement the procedures specified in this document).
特定のVPNのVPNルーティングおよび転送テーブル（VRF）を維持するPEのセットを検討してください。このVPNのコンテキストでは、これらのPEのサブセットを「仮想スポーク」PE（または仮想スポーク）として指定しますが、これらのPEの他の（重複しない）サブセットは「仮想ハブ」PE（または単に仮想スポーク）になりますハブ）。セット内の残りのPEは「バニラ」PE（[RFC4364]で説明されている手順を実装するが、このドキュメントで指定されている手順を実装しないPE）になります。
For the sake of brevity, we will use the term "V-hub" to denote a Virtual Hub and "V-spoke" to denote a Virtual Spoke.
簡潔にするために、「Vハブ」という用語は仮想HUBを示し、「Vスポーク」は仮想スポークを示すために使用します。
For a given VPN, its set of V-hubs may include not only the PEs that have sites of that VPN connected to them but also PEs that have no sites of that VPN connected to them. On such PEs, the VRF associated with that VPN may import routes from other VRFs of that VPN, even if the VRF has no sites of that VPN connected to it.
特定のVPNの場合、そのVハブのセットには、そのVPNのサイトが接続されているPEだけでなく、そのVPNのサイトが接続されていないPEも含まれる場合があります。そのようなPEでは、VRFに接続されているそのVPNのサイトがない場合でも、そのVPNに関連付けられたVRFがそのVPNの他のVRFからルートをインポートする場合があります。
Note that while in the context of one VPN a given PE may act as a V-hub, in the context of another VPN, the same PE may act as a V-spoke, and vice versa. Thus, a given PE may act as a V-hub only for some, but not all, VPNs present on that PE. Likewise, a given PE may act as a V-spoke only for some, but not all, VPNs present on that PE.
1つのVPNのコンテキストでは特定のPEがVハブとして機能する場合がありますが、別のVPNのコンテキストでは同じPEがVスポークとして機能する場合があり、その逆の場合もあります。したがって、特定のPEは、そのPEに存在するすべてではなく一部のVPNに対してのみVハブとして機能する可能性があります。同様に、特定のPEは、そのPEに存在するすべてではなく一部のVPNに対してのみVスポークとして機能する場合があります。
For a given VPN, each V-spoke of that VPN is "associated" with one or more V-hubs of that VPN (one may use two V-hubs for redundancy to avoid a single point of failure). Note that a given V-hub may have no V-spokes associated with it. For more on how a V-spoke and a V-hub become "associated" with each other, see Section 3.
特定のVPNの場合、そのVPNの各Vスポークは、そのVPNの1つ以上のVハブに「関連付けられています」（単一障害点を回避するために、冗長性のために2つのVハブを使用できます）。特定のVハブには、Vスポークが関連付けられていない場合があることに注意してください。 VスポークとVハブがどのように互いに「関連付けられる」かについての詳細は、セクション3を参照してください。
Consider a set of V-spokes that are associated with a given V-hub, V-hub-1. If one of these V-spokes is also associated with some other V-hub, V-hub-2, then other V-spokes in the set need not be associated with the same V-hub, V-hub-2, but may be associated with some other V-hubs (e.g., V-hub-3, V-hub-4, etc.).
特定のVハブV-hub-1に関連付けられているVスポークのセットを考えます。これらのVスポークの1つが他のVハブV-hub-2にも関連付けられている場合、セット内の他のVスポークを同じVハブV-hub-2に関連付ける必要はありませんが、他のいくつかのVハブ（たとえば、Vハブ3、Vハブ4など）に関連付けられている。
This document defines a VPN-IP default route as a VPN-IP route whose VPN-IP prefix contains only a Route Distinguisher (RD) (for the definition of "VPN-IP route", see [RFC4364]).
このドキュメントでは、VPN-IPデフォルトルートを、VPN-IPプレフィックスにルート識別子（RD）のみが含まれるVPN-IPルートとして定義しています（「VPN-IPルート」の定義については、[RFC4364]を参照）。
A PE that acts as a V-hub of a given VPN maintains all routes of that VPN (such a PE imports routes from all other V-hubs and V-spokes, as well as from "vanilla" PEs of that VPN). A PE that acts as a V-spoke of a given VPN needs to maintain only the routes of that VPN that are originated by the sites of that VPN connected to that PE, plus one or more VPN-IP default routes originated by the V-hub(s) associated with that V-spoke (such a PE needs to import only VPN-IP default routes from certain V-hubs). This way, only a subset of PEs that maintain VRFs of a given VPN -- namely, only the PEs acting as V-hubs of that VPN -- has to maintain all routes of that VPN. PEs acting as V-spokes of that VPN need to maintain only a (small) subset of the routes of that VPN.
特定のVPNのVハブとして機能するPEは、そのVPNのすべてのルートを維持します（そのようなPEは、他のすべてのVハブおよびVスポークから、およびそのVPNの「バニラ」PEからルートをインポートします）。特定のVPNのVスポークとして機能するPEは、そのPEに接続されたVPNのサイトから発信されたVPNのルートと、V-から発信された1つ以上のVPN-IPデフォルトルートのみを維持する必要がありますそのVスポークに関連付けられたハブ（そのようなPEは、特定のVハブからVPN-IPデフォルトルートのみをインポートする必要がある）このように、特定のVPNのVRFを維持するPEのサブセットのみ、つまり、そのVPNのVハブとして機能するPEのみが、そのVPNのすべてのルートを維持する必要があります。そのVPNのVスポークとして機能するPEは、そのVPNのルートの（小さな）サブセットのみを維持する必要があります。
This document assumes that a given V-hub and its associated V-spoke(s) are in the same Autonomous System (AS). However, if PEs that maintain a given VPN's VRFs span multiple ASes, this document does not restrict all V-hubs of that VPN to be in the same AS -- the V-hubs may be spread among these ASes.
このドキュメントでは、特定のVハブとそれに関連するVスポークが同じ自律システム（AS）にあると想定しています。ただし、特定のVPNのVRFを維持するPEが複数のASにまたがっている場合、このドキュメントでは、そのVPNのすべてのVハブが同じASにあることを制限していません-VハブはこれらのASに分散している場合があります。
One could model the approach defined in this document as a two-level hierarchy, where the top level consists of V-hubs and the bottom level consists of V-spokes. Generalization of this approach to more than two levels of hierarchy is outside the scope of this document.
このドキュメントで定義されているアプローチを2レベルの階層としてモデル化できます。この場合、トップレベルはVハブで構成され、ボトムレベルはVスポークで構成されます。 3レベル以上の階層へのこのアプローチの一般化は、このドキュメントの範囲外です。
When PEs use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among the PEs. This is because a PE that acts as a V-spoke of a given VPN would need to replicate multicast traffic only to other V-hubs (while other V-hubs would replicate this traffic to the V-spokes associated with these V-hubs), rather than to all PEs of that VPN. Likewise, a PE that acts as a V-hub of a given VPN would need to replicate multicast traffic to other V-hubs and the V-spokes, but only the V-spokes associated with that V-hub, rather than replicating the traffic to all PEs of that VPN. Limiting replication could be especially beneficial if the V-spoke PEs have limited replication capabilities and/or have links with limited bandwidth.
PEが入力レプリケーションを使用してVPNカスタマーのマルチキャストトラフィックを伝送する場合、このドキュメントで説明するアプローチは、特定の状況下で、入力レプリケーションに関連する帯域幅の非効率性を低減し、PE間でレプリケーション負荷を再分散します。これは、特定のVPNのVスポークとして機能するPEが他のVハブにのみマルチキャストトラフィックを複製する必要があるためです（他のVハブはこれらのVハブに関連付けられたVスポークにこのトラフィックを複製します）そのVPNのすべてのPEではなく。同様に、特定のVPNのVハブとして機能するPEは、マルチキャストトラフィックを他のVハブとVスポークに複製する必要がありますが、トラフィックを複製するのではなく、そのVハブに関連付けられたVスポークのみが必要です。そのVPNのすべてのPEに。レプリケーションを制限すると、Vスポーク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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Routing information exchange among all PEs of a given VPN is subject to the following rules.
特定のVPNのすべてのPE間のルーティング情報交換には、次のルールが適用されます。
A PE that has sites of a given VPN connected to it has to retain routing information received from these sites, irrespective of whether this PE acts as a V-hub or a V-spoke of that VPN and follows the rules specified in [RFC4364].
特定のVPNのサイトが接続されているPEは、このPEがそのVPNのVハブまたはVスポークとして機能し、[RFC4364]で指定されたルールに従うかどうかに関係なく、これらのサイトから受信したルーティング情報を保持する必要があります。
A PE that has sites of a given VPN connected to it follows the rules specified in [RFC4364] when exporting (as VPN-IP routes) the routes received from these sites, irrespective of whether this PE acts as a V-hub or a V-spoke of that VPN.
特定のVPNのサイトが接続されているPEは、これらのサイトから受信したルートを（VPN-IPルートとして）エクスポートするときに、[RFC4364]で指定されたルールに従います。このPEがVハブとして機能するかVとして機能するかは関係ありません。 -そのVPNのスポーク。
In addition, a V-hub of a given VPN MUST export a VPN-IP default route for that VPN. This route MUST be exported to only the V-spokes of that VPN that are associated with that V-hub.
さらに、特定のVPNのVハブは、そのVPNのVPN-IPデフォルトルートをエクスポートする必要があります。このルートは、そのVハブに関連付けられているそのVPNのVスポークにのみエクスポートする必要があります。
To enable a given VPN's V-spoke to share its outbound traffic load among the V-hubs associated with that V-spoke, each of the VPN's V-hubs MUST use a distinct RD (per V-hub, per VPN) when originating a VPN-IP default route. The use of Type 1 RDs may be an attractive option for such RDs.
特定のVPNのVスポークがそのVスポークに関連付けられたVハブ間で発信トラフィックの負荷を共有できるようにするには、各VPNのVハブが、発信時に個別のRD（Vハブごと、VPNごと）を使用する必要があります。 VPN-IPデフォルトルート。タイプ1 RDの使用は、そのようなRDにとって魅力的なオプションになる可能性があります。
If a V-spoke imports several VPN-IP default routes, each originated by its own V-hub, and these routes have the same preference, then traffic from the V-spoke to other sites of that VPN would be load shared among the V-hubs.
Vスポークが複数のVPN-IPデフォルトルートをインポートし、それぞれが独自のVハブによって発信され、これらのルートが同じ優先度を持つ場合、VスポークからそのVPNの他のサイトへのトラフィックはV間で負荷分散されます-ハブ。
Following the rules specified in [RFC4364], a V-hub of a given VPN imports all the non-default VPN-IP routes originated by all other PEs that have sites of that VPN connected to them (irrespective of whether these other PEs act as V-hubs or V-spokes or just "vanilla" PEs for that VPN, and irrespective of whether or not these V-spokes are associated with the V-hub).
[RFC4364]で指定されたルールに従って、特定のVPNのVハブは、VPNのサイトが接続されている他のすべてのPEから発信されたデフォルト以外のすべてのVPN-IPルートをインポートします（これらの他のPEがVハブまたはVスポーク、またはそのVPNの単なる「バニラ」PE。これらのVスポークがVハブに関連付けられているかどうかには関係ありません）。
A V-hub of a given VPN MUST NOT import a VPN-IP default route unless the imported route is the Internet VPN-IP default route (for the definition of "Internet VPN-IP default route" and information on how to distinguish between a VPN-IP default route and the Internet VPN-IP default route, see Section 5).
特定のVPNのVハブは、インポートされたルートがインターネットVPN-IPデフォルトルート（「インターネットVPN-IPデフォルトルート」の定義と、 VPN-IPデフォルトルートとインターネットVPN-IPデフォルトルート。セクション5を参照）。
Within a given VPN, a V-spoke MUST import all VPN-IP default routes that have been originated by the V-hubs associated with that V-spoke.
特定のVPN内で、Vスポークは、そのVスポークに関連付けられたVハブによって発信されたすべてのVPN-IPデフォルトルートをインポートする必要があります。
In addition, a V-spoke of a given VPN MAY import VPN-IP routes for that VPN that have been originated by some other V-spokes of that VPN, but only by the V-spokes that are associated with the same V-hub(s) as the V-spoke itself.
さらに、特定のVPNのVスポークは、そのVPNの他の一部のVスポークによって発信されたが、同じVハブに関連付けられているVスポークによってのみ発信された、そのVPNのVPN-IPルートをインポートできます（MAY） （s）Vスポーク自体として。
The above rules are realized by using Route Target (RT) extended communities [RFC4360] and VRF export/import policies based on these RTs. This document defines the following procedures for implementing the above rules.
上記のルールは、ルートターゲット（RT）拡張コミュニティ[RFC4360]と、これらのRTに基づくVRFエクスポート/インポートポリシーを使用することで実現されます。このドキュメントでは、上記のルールを実装するための次の手順を定義します。
Consider a "vanilla" any-to-any VPN. This document assumes that all the PEs of that VPN (or to be more precise, all VRFs of that VPN) are provisioned with the same export and import RT -- we will refer to this RT as "RT-VPN" (of course, for a given VPN service provider, each VPN would use its own RT-VPN, distinct from RT-VPNs used by other VPNs).
「バニラ」のAny-to-Any VPNを検討してください。このドキュメントでは、そのVPNのすべてのPE（より正確には、そのVPNのすべてのVRF）に同じエクスポートおよびインポートRTがプロビジョニングされていることを前提としています-このRTを「RT-VPN」と呼びます（もちろん、特定のVPNサービスプロバイダーでは、各VPNは独自のRT-VPNを使用しますが、他のVPNで使用されるRT-VPNとは異なります）。
To evolve this VPN into V-hubs and V-spokes, all PEs (or to be more precise, all VRFs) that are designated as either V-hubs or V-spokes of that VPN keep the same export RT-VPN. This RT-VPN is attached to all VPN-IP routes originated by these PEs. Also, all the V-hubs keep the same import RT-VPN.
このVPNをVハブおよびVスポークに進化させるために、そのVPNのVハブまたはVスポークとして指定されているすべてのPE（より正確には、すべてのVRF）は、同じエクスポートRT-VPNを保持します。このRT-VPNは、これらのPEから発信されたすべてのVPN-IPルートに接続されます。また、すべてのVハブは同じインポートRT-VPNを維持します。
In addition, each of a given VPN's V-hubs is provisioned with its own export RT, called RT-VH. This RT-VH MUST be different from the export RT (RT-VPN) provisioned on that V-hub. Furthermore, for a given VPN service provider, no two VPNs can use the same RT-VH.
さらに、特定のVPNの各Vハブには、RT-VHと呼ばれる独自のエクスポートRTがプロビジョニングされます。このRT-VHは、そのVハブでプロビジョニングされたエクスポートRT（RT-VPN）とは異なる必要があります。さらに、特定のVPNサービスプロバイダーに対して、2つのVPNが同じRT-VHを使用することはできません。
A given V-spoke becomes associated with a given V-hub by virtue of provisioning the V-spoke to import only the VPN-IP route(s) that carry RT-VH provisioned on the V-hub (thus, associating a new V-spoke with a given V-hub requires provisioning only on that V-spoke -- no provisioning changes are required on the V-hub).
Vスポークをプロビジョニングして、VハブでプロビジョニングされたRT-VHを伝送するVPN-IPルートのみをインポートすることにより、特定のVスポークが特定のVハブに関連付けられます（したがって、新しいVを関連付けます） -特定のVハブでのスポークは、そのVスポークでのみプロビジョニングが必要です-Vハブでのプロビジョニングの変更は必要ありません）。
To avoid the situation where within a given VPN all the V-spokes would be associated with every V-hub (in other words, to partition V-spokes among V-hubs), different V-hubs within that VPN MAY use different RT-VHs. At one extreme, every V-hub may use a distinct RT-VH. The use of IP-address-specific RTs may be an attractive option for this scenario. However, it is also possible for several V-hubs to use the same RT-VH, in which case all of these V-hubs would be associated with the same set of V-spokes.
特定のVPN内ですべてのVスポークがすべてのVハブに関連付けられる（つまり、VスポークをVハブ間で分割する）状況を回避するために、そのVPN内の異なるVハブは異なるRTを使用してもよい（MAY） VH。極端な例として、すべてのVハブが個別のRT-VHを使用することがあります。このシナリオでは、IPアドレス固有のRTの使用が魅力的なオプションになる場合があります。ただし、複数のVハブが同じRT-VHを使用することも可能です。その場合、これらのVハブはすべて同じVスポークのセットに関連付けられます。
When a V-hub originates a (non-Internet) VPN-IP default route, the V-hub MUST attach RT-VH to that route (the case where a V-hub originates the Internet VPN-IP default route is covered in Section 5). Thus, this route is imported by all V-spokes associated with the V-hub.
Vハブが（非インターネット）VPN-IPデフォルトルートを発信する場合、VハブはそのルートにRT-VHをアタッチする必要があります（VハブがインターネットVPN-IPデフォルトルートを発信する場合については、 5）。したがって、このルートは、Vハブに関連付けられているすべてのVスポークによってインポートされます。
A V-spoke MAY be provisioned to export VPN-IP routes not just to the V-hubs but also to the V-spokes that import the same VPN-IP default route(s) as the V-spoke itself. The V-spoke accomplishes this by adding its import RT-VH(s) to the VPN-IP routes exported by the V-spoke.
V-スポークは、V-ハブだけでなく、V-スポーク自体と同じVPN-IPデフォルトルートをインポートするV-スポークにもVPN-IPルートをエクスポートするようにプロビジョニングされる場合があります。 Vスポークは、VスポークによってエクスポートされたVPN-IPルートにインポートRT-VHを追加することでこれを実現します。
This section describes changes/modifications to the forwarding procedures specified in [RFC4364].
このセクションでは、[RFC4364]で指定されている転送手順の変更/修正について説明します。
For a given VPN, the MPLS label that a V-hub of that VPN advertises with a VPN-IP default route MUST be the label that is mapped to a Next Hop Label Forwarding Entry (NHLFE) that identifies the VRF of the V-hub. As a result, when the V-hub receives a packet that carries such a label, the V-hub pops the label and determines further disposition of the packet based on the lookup in the VRF.
特定のVPNについて、そのVPNのVハブがVPN-IPデフォルトルートでアドバタイズするMPLSラベルは、VハブのVRFを識別するネクストホップラベル転送エントリ（NHLFE）にマップされるラベルである必要があります。その結果、Vハブがそのようなラベルを含むパケットを受信すると、Vハブはラベルをポップし、VRFのルックアップに基づいてパケットの処理を決定します。
Note that this document does not require the advertisement of labels mapped to an NHLFE that identifies a VRF for routes other than the VPN-IP default route.
このドキュメントでは、VPN-IPデフォルトルート以外のルートのVRFを識別するNHLFEにマッピングされたラベルのアドバタイズメントは必要ないことに注意してください。
When a V-hub of a given VPN originates a VPN-IP default route for that VPN, the V-hub MUST NOT install in its VRF of that VPN a default route, unless that route has been originated as a result of
特定のVPNのVハブがそのVPNのVPN-IPデフォルトルートを発信する場合、そのルートが次の結果として発信されていない限り、VハブはそのVPNのVRFにデフォルトルートをインストールしてはなりません（MUST NOT）。
a) the V-hub receiving an IP default route from one of the VPN Customer Edge (CE) routers connected to it, or
a) 接続されているVPNカスタマーエッジ（CE）ルーターの1つからIPデフォルトルートを受信するVハブ、または
b) the V-hub receiving (and importing) the Internet VPN-IP default route (Section 5) from some other PE, or
b) 他のPEからインターネットVPN-IPデフォルトルート（セクション5）を受信（およびインポート）するVハブ、または
c) the VRF being provisioned with a default route pointing to the routing table that maintains the Internet routes.
c) インターネットルートを維持するルーティングテーブルを指すデフォルトルートでプロビジョニングされるVRF。
When a multihomed site is connected to a V-hub and a V-spoke, then the V-hub uses the following OPTIONAL procedures to support Internal BGP (IBGP) / External BGP (EBGP) load balancing for the site's inbound traffic that has been originated by some other V-spoke associated with the V-hub. When the V-hub receives from some other PE a packet that carries an MPLS label that the V-hub advertised in the VPN-IP default route, then the V-hub uses the label to identify the VRF that should be used for further disposition of the packet. If (using the information present in the VRF) the V-hub determines that the packet has to be forwarded using a non-default route present in the VRF, and this route indicates that the packet's destination is reachable either over one of the VRF attachment circuits (for the definition of "VRF attachment circuits", see [RFC4364]) or via some other (V-spoke) PE, the V-hub forwards the packet either over this attachment circuit or via that other PE. The choice between the two is a local matter to the V-hub.
マルチホームサイトがVハブおよびVスポークに接続されている場合、Vハブは次のオプションの手順を使用して、サイトの受信トラフィックの内部BGP（IBGP）/外部BGP（EBGP）負荷分散をサポートしますVハブに関連付けられた他のVスポークによって発信されました。 Vハブが他のPEから、VハブがVPN-IPデフォルトルートでアドバタイズしたMPLSラベルを含むパケットを受信すると、Vハブはそのラベルを使用して、後処理に使用するVRFを識別しますパケットの。 （VRFに存在する情報を使用して）V-hubが、VRFに存在するデフォルト以外のルートを使用してパケットを転送する必要があると判断した場合、このルートは、パケットの宛先がいずれかのVRFアタッチメントを介して到達可能であることを示します回路（「VRF接続回路」の定義については、[RFC4364]を参照）または他の（Vスポーク）PEを介して、Vハブはこの接続回路または他のPEを介してパケットを転送します。 2つの間の選択は、Vハブのローカルな問題です。
To illustrate this, consider the following example:
これを説明するために、次の例を考えます。
<- RD:0/0 RD:0/0->
<- RD:192.0.2 <-192.0.2/24
CE1----PE-S-------------PE-H----------------PE-S1-------------CE2
/
| |
| | 192.0.2/24
| |
CE4 CE3
A multihomed site (not shown in the above figure) is connected via CE2 and CE3. Thus, both CE2 and CE3 advertise a route to 192.0.2/24. CE2 advertises this route (route to 192.0.2/24) to PE-S1, which in turn originates a VPN-IP route RD:192.0.2. CE3 advertises this route to PE-H.
マルチホームサイト（上の図には表示されていません）は、CE2とCE3を介して接続されています。したがって、CE2とCE3の両方がルートを192.0.2 / 24にアドバタイズします。 CE2はこのルート（192.0.2 / 24へのルート）をPE-S1にアドバタイズし、PE-S1はVPN-IPルートRD：192.0.2を発信します。 CE3はこのルートをPE-Hにアドバタイズします。
PE-H is a V-hub, while PE-S and PE-S1 are V-spokes associated with that V-hub. Thus, PE-H originates a VPN-IP default route (RD:0/0), and both PE-S and PE-S1 import that route.
PE-HはVハブですが、PE-SおよびPE-S1はそのVハブに関連付けられたVスポークです。したがって、PE-HはVPN-IPデフォルトルート（RD：0/0）を発信し、PE-SとPE-S1の両方がそのルートをインポートします。
PE-H receives from PE-S1 a VPN-IP route to RD:192.0.2 and from CE3 a plain IP route to 192.0.2. Thus, the VRF entry on PE-H has two possible next hops for 192.0.2: CE3 and PE-S1 (the latter is a next hop that is not directly connected to PE-H).
PE-HはPE-S1からRD：192.0.2へのVPN-IPルートを受信し、CE3から192.0.2へのプレーンIPルートを受信します。したがって、PE-HのVRFエントリには、192.0.2の2つの可能なネクストホップがあります。CE3とPE-S1です（後者は、PE-Hに直接接続されていないネクストホップです）。
Now consider what happens when CE1 originates a packet destined to 192.0.2.1. When PE-S receives this packet, PE-S (following the VPN-IP default route) forwards the packet to PE-H. The MPLS label in the packet is the label that PE-H advertised to PE-S in the VPN-IP default route. Thus, following the rule specified above, PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the packet to CE2), resulting in IBGP/EBGP load balancing.
ここで、CE1が192.0.2.1宛てのパケットを発信するとどうなるかを考えます。 PE-Sがこのパケットを受信すると、（VPN-IPのデフォルトルートに従って）PE-SがパケットをPE-Hに転送します。パケットのMPLSラベルは、VPN-IPデフォルトルートでPE-HがPE-Sにアドバタイズしたラベルです。したがって、上記で指定されたルールに従って、PE-HはCE3またはPE-S1を介してパケットを転送し（PE-S1はその後パケットをCE2に転送します）、IBGP / EBGPロードバランシングが行われます。
Likewise, if CE4 originates a packet destined to 192.0.2.1, PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the traffic to CE2), resulting in IBGP/EBGP load balancing.
同様に、CE4が192.0.2.1宛てのパケットを発信した場合、PE-HはCE3またはPE-S1を介してパケットを転送し（PE-S1はその後トラフィックをCE2に転送する）、IBGP / EBGPロードバランシングが行われます。
Note, however, that if there is some other CE, CE5, connected to PE-S1, and CE5 sends a packet to 192.0.2.1, then (due to the IP longest match rule) PE-S1 will always forward this packet to CE2.
ただし、PE-S1に接続されている他のCE、CE5があり、CE5が192.0.2.1にパケットを送信する場合、（IP最長一致ルールにより）PE-S1は常にこのパケットをCE2に転送することに注意してください。 。
Thus, for a multihomed site connected to a V-hub and a V-spoke, IBGP/EBGP load balancing will be available for some but not all the traffic destined to that site. Specifically, IBGP/EBGP load balancing will not be available for the traffic destined to that site if this traffic has been originated within some other site that is connected to the same V-spoke.
したがって、VハブおよびVスポークに接続されたマルチホームサイトの場合、そのサイト宛てのトラフィックのすべてではなく一部に対してIBGP / EBGPロードバランシングを使用できます。具体的には、このトラフィックが同じVスポークに接続されている他のサイト内で発信されている場合、そのサイト宛てのトラフィックに対してIBGP / EBGPロードバランシングは利用できません。
Moreover, if CE3 advertises 192.0.2.0/25 and 192.0.2/24, while CE2 advertises 192.0.2.128/25 and 192.0.2/24 (which is yet another form of load balancing for a multihomed site), when CE5 sends a packet to 192.0.2.1, then (due to the IP longest match rule) PE-S1 will always forward this packet to CE2, even though the VPN customer would expect this traffic to flow via CE3.
さらに、CE3が192.0.2.0/25および192.0.2 / 24をアドバタイズし、CE2が192.0.2.128/25および192.0.2 / 24をアドバタイズする場合（これはマルチホームサイトのロードバランシングの別の形式です）、CE5がその後、（IP最長一致ルールにより）PE-S1は常にこのパケットをCE2に転送しますが、VPNの顧客はこのトラフィックがCE3経由で流れることを期待しています。
This document proposes two options to address the issues raised in the previous two paragraphs. The first option is to disallow a given VPN to provision PEs that have multihomed sites of that VPN connected to them as V-spokes (such PEs could be provisioned as either V-hubs or plain "vanilla" PEs). The second option is for the V-spoke, when it receives an IP route from a CE, to not install this route in its forwarding table but just re-advertise this route as a VPN-IP route, together with an MPLS label. The NHLFE [RFC3031] associated with that label MUST specify the CE that advertises the IP route as the next hop. As a result, when the PE receives data that carries that label, the PE just forwards the data to the CE without performing an IP lookup on the data. Note that doing this would result in forcing the traffic between a pair of sites connected to the same V-spoke to go through the V-hub of that V-spoke.
このドキュメントは、前の2つの段落で提起された問題に対処するための2つのオプションを提案します。最初のオプションは、特定のVPNが、そのVPNのマルチホームサイトがVスポークとして接続されているPEをプロビジョニングできないようにすることです（そのようなPEは、Vハブまたはプレーンな「バニラ」PEとしてプロビジョニングできます）。 2番目のオプションは、VスポークがCEからIPルートを受信したときに、このルートを転送テーブルにインストールせず、MPLSラベルとともにこのルートをVPN-IPルートとして再アドバタイズすることです。そのラベルに関連付けられたNHLFE [RFC3031]は、IPルートをネクストホップとしてアドバタイズするCEを指定する必要があります。その結果、PEがそのラベルを含むデータを受信すると、PEはデータに対してIPルックアップを実行せずに、データをCEに転送するだけです。これを行うと、同じVスポークに接続されたサイトのペア間のトラフィックが、そのVスポークのVハブを通過するように強制されることに注意してください。
An implementation that supports IBGP/EBGP load balancing, as specified above, SHOULD support the second option. If the implementation does not support the second option, then deploying this implementation to support IBGP/EBGP load balancing, as specified above, would either (a) restrict the set of PEs that could be provisioned as V-spokes (any PE that has a multihomed site connected to it cannot be provisioned as a V-spoke) or (b) result in IBGP/EBGP load balancing not being available for certain scenarios (the scenarios that the second option is intended to cover).
上で指定したように、IBGP / EBGPロードバランシングをサポートする実装は、2番目のオプションをサポートする必要があります（SHOULD）。実装が2番目のオプションをサポートしていない場合、上記のようにIBGP / EBGPロードバランシングをサポートするためにこの実装を展開すると、（a）VスポークとしてプロビジョニングできるPEのセット（接続されたマルチホームサイトはVスポークとしてプロビジョニングできません）または（b）特定のシナリオ（2番目のオプションが対象とするシナリオ）でIBGP / EBGPロードバランシングを利用できない。
This document specifies two possible alternatives for providing Internet connectivity for a given VPN.
このドキュメントでは、特定のVPNにインターネット接続を提供するための2つの代替案を示します。
The first alternative is when a PE that maintains Internet routes also maintains a VRF of a given VPN. In this case, the Internet connectivity for that VPN MAY be provided by provisioning a default route in the VPN's VRF on that PE pointing to the routing table on that PE that maintains the Internet routes. This PE MUST NOT be provisioned as a V-spoke for that VPN (this PE may be provisioned as either a V-hub or a "vanilla" PE). If this PE is provisioned as a V-hub, then this PE MUST originate a VPN-IP default route. The route MUST carry both RT-VPN and RT-VH of the V-hub (see Section 3 for the definitions of "RT-VPN" and "RT-VH"). Thus, this route will be imported by all the V-spokes associated with the V-hub, as well as by other V-hubs and "vanilla" PEs. An implementation MUST support the first alternative.
最初の選択肢は、インターネットルートを維持するPEが、特定のVPNのVRFも維持する場合です。この場合、そのVPNのインターネット接続は、そのPE上のVPNのVRFに、インターネットルートを維持するそのPE上のルーティングテーブルを指すデフォルトルートをプロビジョニングすることによって提供される場合があります。このPEは、そのVPNのVスポークとしてプロビジョニングしてはなりません（このPEは、Vハブまたは「バニラ」PEのいずれかとしてプロビジョニングできます）。このPEがVハブとしてプロビジョニングされている場合、このPEはVPN-IPデフォルトルートを発信する必要があります。ルートは、VハブのRT-VPNとRT-VHの両方を伝送する必要があります（「RT-VPN」と「RT-VH」の定義については、セクション3を参照してください）。したがって、このルートは、Vハブに関連付けられているすべてのVスポーク、および他のVハブと「バニラ」PEによってインポートされます。実装は最初の選択肢をサポートしなければなりません（MUST）。
The second alternative is when a site of a given VPN has connection to the Internet, and a CE of that site advertises an IP default route to the PE connected to that CE. This alternative has two subcases: (a) the PE is provisioned as a V-hub, and (b) the PE is provisioned as a V-spoke. An implementation MUST support subcase (a). An implementation MAY support subcase (b).
2番目の選択肢は、特定のVPNのサイトがインターネットに接続していて、そのサイトのCEが、そのCEに接続されているPEへのIPデフォルトルートをアドバタイズする場合です。この代替案には2つのサブケースがあります。（a）PEはVハブとしてプロビジョニングされ、（b）PEはVスポークとしてプロビジョニングされます。実装はサブケース（a）をサポートする必要があります。実装はサブケース（b）をサポートしてもよい（MAY）。
If a PE is provisioned as a V-hub, then the PE re-advertises this IP default route as a VPN-IP default route and installs in its VRF an IP default route with the next hop specifying the CE(s) that advertise the IP default route to the PE. Note that when re-advertising the VPN-IP default route, the route MUST carry both RT-VPN and RT-VH of the V-hub (see Section 3 for the definitions of "RT-VPN" and "RT-VH"). Thus, this route will be imported by all the V-spokes associated with the V-hub, as well as by other V-hubs and "vanilla" PEs.
PEがVハブとしてプロビジョニングされている場合、PEはこのIPデフォルトルートをVPN-IPデフォルトルートとして再アドバタイズし、そのVRFにIPデフォルトルートをインストールします。ネクストホップは、 PEへのIPデフォルトルート。 VPN-IPデフォルトルートを再アドバタイズする場合、ルートはVハブのRT-VPNとRT-VHの両方を伝送する必要があることに注意してください（「RT-VPN」と「RT-VH」の定義についてはセクション3を参照） 。したがって、このルートは、Vハブに関連付けられているすべてのVスポーク、および他のVハブと「バニラ」PEによってインポートされます。
If a PE is provisioned as a V-spoke, then receiving a default route from a CE MUST NOT cause the V-spoke to install an IP default route in its VRF. The V-spoke MUST originate a VPN-IP default route with a (non-null) MPLS label. The route MUST carry only RT-VPN (as a result, this route is not imported by any of the V-spokes but is imported by V-hubs). The packet's next hop of the NHLFE [RFC3031] associated with that label MUST specify the CE that advertises the IP default route. As a result, when the V-spoke receives data that carries that label, it just forwards the data to the CE without performing an IP lookup on the data. Note that in this case, the VRF on the V-spoke will have an IP default route, but this route would be created as a result of receiving a VPN-IP default route from one of the V-hubs associated with that V-spoke (and not as a result of receiving the IP default route from the CE). Note also that if this V-spoke has other sites of that VPN connected to it, then traffic from these sites to the Internet would go to that V-spoke, then to the V-hub selected by the V-spoke, then from that V-hub back to the V-spoke, and then to the CE that advertises an IP default route to the V-spoke.
PEがVスポークとしてプロビジョニングされている場合、CEからデフォルトルートを受信しても、VスポークがVRFにIPデフォルトルートをインストールしてはなりません。 Vスポークは、（非null）MPLSラベルを使用してVPN-IPデフォルトルートを発信する必要があります。ルートはRT-VPNのみを伝送する必要があります（その結果、このルートはどのVスポークによってもインポートされませんが、Vハブによってインポートされます）。そのラベルに関連付けられたNHLFE [RFC3031]のパケットのネクストホップは、IPデフォルトルートをアドバタイズするCEを指定する必要があります。その結果、Vスポークがそのラベルが付いたデータを受信すると、データに対してIPルックアップを実行せずに、データをCEに転送するだけです。この場合、Vスポーク上のVRFにはIPデフォルトルートがありますが、このルートは、そのVスポークに関連付けられたVハブの1つからVPN-IPデフォルトルートを受信した結果として作成されます。 （CEからIPデフォルトルートを受信した結果ではありません）。また、このVスポークにそのVPNの他のサイトが接続されている場合、これらのサイトからインターネットへのトラフィックは、そのVスポーク、次にVスポークによって選択されたVハブ、そしてそこからVハブはVスポークに戻り、次にCEに戻り、IPデフォルトルートをVスポークにアドバタイズします。
If a PE is provisioned as a V-spoke of a given VPN, and if a CE of that VPN advertises an IP default route to the PE (as the CE belongs to the site that provides the Internet connectivity for the VPN), then the PE MUST NOT advertise an IP default route back to that CE. Yet, the CE has to specify that PE as the next hop for all the traffic to other sites of that VPN. A way to accomplish this is to require the V-spoke to implement procedures specified in Section 9.
PEが特定のVPNのVスポークとしてプロビジョニングされ、そのVPNのCEがPEへのIPデフォルトルートをアドバタイズする場合（CEはVPNにインターネット接続を提供するサイトに属しているため）、 PEは、そのCEに戻るIPデフォルトルートをアドバタイズしてはなりません。ただし、CEはそのPEを、そのVPNの他のサイトへのすべてのトラフィックのネクストホップとして指定する必要があります。これを達成する方法は、セクション9で指定された手順をVスポークに実装することを要求することです。
In all the scenarios described above in this section, we refer to the originated VPN-IP default route as the "Internet VPN-IP default route". Specifically, the Internet VPN-IP default route is a VPN-IP default route originated by a PE (this PE could be either a V-hub or a V-spoke) as a result of (a) receiving an IP default route from a CE or (b) the PE maintaining Internet routes and also provisioning in the VRF of its VPN a default route pointing to its (the PE's) routing table that contains Internet routes.
このセクションで前述したすべてのシナリオでは、発生したVPN-IPデフォルトルートを「インターネットVPN-IPデフォルトルート」と呼びます。具体的には、インターネットVPN-IPデフォルトルートは、（a）からIPデフォルトルートを受信した結果として、PE（このPEはVハブまたはVスポークのいずれか）によって開始されたVPN-IPデフォルトルートです。 CEまたは（b）インターネットルートを維持しているPE、およびそのVPNのVRFでのインターネットルートを含む（PEの）ルーティングテーブルを指すデフォルトルートのプロビジョニング。
The difference between the Internet VPN-IP default route and a non-Internet VPN-IP default route originated by a V-hub is in the RTs carried by the route -- for a given VPN and a given V-hub of that VPN, the Internet VPN-IP default route carries both RT-VPN and RT-VH of that V-hub, while the non-Internet VPN-IP default route carries just RT-VH of that V-hub.
V-hubから発信されたインターネットVPN-IPデフォルトルートと非インターネットVPN-IPデフォルトルートの違いは、ルートによって運ばれるRTにあります-特定のVPNとそのVPNの特定のVハブの場合、インターネットVPN-IPデフォルトルートは、そのVハブのRT-VPNとRT-VHの両方を伝送しますが、非インターネットVPN-IPデフォルトルートは、そのVハブのRT-VHのみを伝送します。
When a V-hub originates the Internet VPN-IP default route, the V-hub MUST withdraw the non-Internet VPN-IP default route that has been originated by the V-hub. When a V-hub withdraws the Internet VPN-IP default route that has been originated by the V-hub, the V-hub MUST originate a non-Internet VPN-IP default route. That is, at any given point in time, a given V-hub originates either the Internet VPN-IP default route or a non-Internet VPN-IP default route.
VハブがインターネットVPN-IPデフォルトルートを発信する場合、Vハブは、Vハブが発信した非インターネットVPN-IPデフォルトルートを撤回する必要があります。 VハブがVハブから発信されたインターネットVPN-IPデフォルトルートを撤回する場合、Vハブは非インターネットVPN-IPデフォルトルートを発信する必要があります。つまり、特定の時点で、特定のVハブは、インターネットVPN-IPデフォルトルートまたは非インターネットVPN-IPデフォルトルートのいずれかを発信します。
As a result of the rules specified above, if a V-hub originates the Internet VPN-IP default route, then all the V-spokes associated with that V-hub MUST import that route. In addition (and in contrast with a non-Internet VPN-IP default route), other V-hubs MAY import that route. A V-hub MAY also import the Internet VPN-IP default routes originated by V-spoke(s). A V-spoke MUST NOT import the Internet VPN-IP default route originated by any other V-spoke. Such a route MAY be imported only by V-hubs.
上記のルールの結果、VハブがインターネットVPN-IPデフォルトルートを発信する場合、そのVハブに関連付けられたすべてのVスポークはそのルートをインポートする必要があります。さらに（インターネット以外のVPN-IPのデフォルトルートとは対照的に）、他のVハブはそのルートをインポートできます（MAY）。 Vハブは、Vスポークから発信されたインターネットVPN-IPデフォルトルートもインポートできます（MAY）。 Vスポークは、他のVスポークから発信されたインターネットVPN-IPデフォルトルートをインポートしてはなりません（MUST NOT）。このようなルートは、Vハブによってのみインポートされる場合があります。
If the Internet VPN-IP default route originated by a V-hub has the same preference as the (non-Internet) VPN-IP default route originated by some other V-hub, then a V-spoke that imports VPN-IP default routes originated by both of these V-hubs would load share the outgoing Internet traffic between these two V-hubs (and thus some of the outgoing Internet traffic from that V-spoke will first be routed to the V-hub that does not originate the Internet VPN-IP default route, then from that V-hub to the V-hub that does originate the Internet VPN-IP default route).
Vハブによって発信されたインターネットVPN-IPデフォルトルートが、他のVハブによって発信された（インターネット以外の）VPN-IPデフォルトルートと同じ優先順位を持つ場合、VPN-IPデフォルトルートをインポートするVスポークこれらのVハブの両方によって発信された場合、これら2つのVハブ間の発信インターネットトラフィックがロードシェアリングされます（したがって、そのVスポークからの発信インターネットトラフィックの一部は、最初にインターネットを発信しないVハブにルーティングされますVPN-IPデフォルトルート、次にそのVハブからインターネットVPN-IPデフォルトルートを発信するVハブへ）。
If taking an extra-hub hop for the Internet traffic is viewed as undesirable, then it is RECOMMENDED that the Internet VPN-IP default route be of higher preference than a (non-Internet) VPN-IP default route originated by some other V-hub. However, in this case the traffic from the V-spokes to other sites of that VPN will not be load shared between these two V-hubs.
インターネットトラフィックにエクストラハブホップを使用することが望ましくないと見なされる場合、インターネットVPN-IPのデフォルトルートが、他のV-によって発信された（非インターネット）VPN-IPのデフォルトルートよりも優先されることをお勧めします。ハブ。ただし、この場合、VスポークからそのVPNの他のサイトへのトラフィックは、これら2つのVハブ間で負荷分散されません。
For a given VPN, a V-hub and a set of V-spokes associated with that V-hub should be chosen in a way that minimizes the additional network distance/latency penalty, given that VPN geographic footprint.
特定のVPNの場合、VハブとそのVハブに関連付けられたVスポークのセットは、VPNの地理的フットプリントを考慮して、追加のネットワーク距離/待ち時間のペナルティを最小限に抑える方法で選択する必要があります。
For a given VPN, some or all of its V-spokes could be grouped into geographically based clusters (e.g., V-spokes within a given cluster could be in close geographical proximity to each other) with any-to-any connectivity within each cluster. Note that the V-spokes within a given cluster need not be associated with the same V-hub(s). Likewise, not all V-spokes associated with a given V-hub need to be in the same cluster. A use case for this would be a VPN for a large retail chain in which data traffic is hub/spoke between each store and centralized datacenters, but there is a need for direct Voice over IP (VoIP) traffic between stores within the same geographical area.
特定のVPNの場合、Vスポークの一部またはすべてを地理的にベースのクラスターにグループ化できます（たとえば、特定のクラスター内のVスポークは地理的に互いに近接している可能性があります）。 。特定のクラスター内のVスポークを同じVハブに関連付ける必要はありません。同様に、特定のVハブに関連付けられているすべてのVスポークが同じクラスターにある必要はありません。このユースケースは、大規模な小売チェーンのVPNであり、データトラフィックは各ストアと集中型データセンターの間のハブ/スポークですが、同じ地理的領域内のストア間の直接Voice over IP（VoIP）トラフィックが必要です。 。
The use of constrained route distribution for BGP/MPLS IP VPNs ("RT constrains") [RFC4684] may further facilitate/optimize routing exchange in support of V-hubs and V-spokes.
BGP / MPLS IP VPN（「RT制約」）[RFC4684]の制約付きルート配信を使用すると、VハブとVスポークをサポートするルーティング交換をさらに促進/最適化できます。
Introducing a V-spoke PE in a VPN may introduce the following changes for the customer of that VPN:
VPNにVスポークPEを導入すると、そのVPNの顧客に次の変更が導入される可能性があります。
+ Traceroute from a CE connected to a V-spoke may report an additional hop: the V-hub PE.
+ Vスポークに接続されたCEからのtracerouteは、追加のホップ、VハブPEを報告する場合があります。
+ Latency for traffic sent from a CE connected to a V-spoke may increase, depending on the location of the V-hub in the layer 3 and layer 1 network topology of the SP.
+ Vスポークに接続されたCEから送信されるトラフィックの遅延は、SPのレイヤー3およびレイヤー1ネットワークトポロジ内のVハブの場所によっては増加する場合があります。
This section describes procedures for supporting Multicast VPN (MVPN) in the presence of Virtual Hub-and-Spoke. The procedures rely on MVPN specifications as defined in [RFC6513], [RFC6514], and [RFC6625].
このセクションでは、仮想HUBアンドスポークの存在下でマルチキャストVPN（MVPN）をサポートする手順について説明します。手順は、[RFC6513]、[RFC6514]、および[RFC6625]で定義されているMVPN仕様に依存しています。
The procedures assume that for the purpose of ensuring non-duplication, both V-hubs and V-spokes can discard packets from a "wrong" PE, as specified in Section 9.1.1 of [RFC6513]. The existing procedures for Selective Provider Multicast Service Interface (S-PMSI) auto-discovery (A-D) routes [RFC6513] [RFC6514] [RFC6625] are sufficient to discard packets coming from a "wrong" PE for all types of provider tunnels (P-tunnels) specified in [RFC6514] (including Ingress Replication). The existing procedures for Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes [RFC6513] [RFC6514] are sufficient to discard packets coming from a "wrong" PE for all types of P-tunnels specified in [RFC6514], except for Ingress Replication. Section 7.9 of this document specifies changes to the procedures in [RFC6514], to enable the discarding of packets from a "wrong" PE when Ingress Replication is used for I-PMSI P-tunnels.
この手順では、[RFC6513]のセクション9.1.1で指定されているように、重複を防止する目的で、VハブとVスポークの両方が「間違った」PEからのパケットを破棄できると想定しています。選択的プロバイダーマルチキャストサービスインターフェイス（S-PMSI）自動検出（AD）ルートの既存の手順[RFC6513] [RFC6514] [RFC6625]は、すべてのタイプのプロバイダートンネル（P）の「間違った」PEからのパケットを破棄するのに十分です-tunnels）[RFC6514]で指定されています（入力レプリケーションを含む）。インクルーシブプロバイダーマルチキャストサービスインターフェイス（I-PMSI）ADルートの既存の手順[RFC6513] [RFC6514]は、[RFC6514]で指定されたすべてのタイプのPトンネルの「間違った」PEからのパケットを破棄するのに十分ですレプリケーション。このドキュメントのセクション7.9は、[RFC6514]の手順の変更を指定して、I-PMSI PトンネルにIngress Replicationが使用されている場合に「間違った」PEからのパケットを破棄できるようにします。
The V-hub/V-spoke architecture, as specified in this document, affects certain multicast scenarios. In particular, it affects multicast scenarios where the source of a multicast flow is at a site attached to a V-hub and a receiver of that flow is at a site attached to a V-spoke that is not associated with that same V-hub. It also affects multicast scenarios where the source of a multicast flow is at a site attached to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V-hub(s) associated with the second V-spoke is empty. It may also affect multicast scenarios where the source of a multicast flow is at a site connected to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V-hub(s) associated with the second V-spoke is non-empty (the multicast scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by the first V-spoke are not imported by the second V-spoke).
このドキュメントで指定されているVハブ/ Vスポークアーキテクチャは、特定のマルチキャストシナリオに影響します。特に、マルチキャストフローのソースがVハブに接続されたサイトにあり、そのフローのレシーバーが同じVハブに関連付けられていないVスポークに接続されたサイトにあるマルチキャストシナリオに影響します。 。また、マルチキャストフローのソースがVスポークに接続されたサイトにあり、そのフローのレシーバーが別のVスポークに接続されたサイトにあり、Vハブ間のセット交差（ s）最初のVスポークに関連付けられ、2番目のVスポークに関連付けられたVハブは空です。また、マルチキャストフローのソースがVスポークに接続されたサイトにあり、そのフローのレシーバーが別のVスポークに接続されたサイトにあり、Vハブ間の設定された交点にあるマルチキャストシナリオにも影響を与える可能性があります最初のVスポークに関連付けられた（s）および2番目のVスポークに関連付けられたVハブが空ではない（最初のVスポークから発信されたI-PMSI / S-PMSI ADルートがマルチキャストシナリオに影響する場合） Vスポークは2番目のVスポークによってインポートされません）。
The use of Virtual Hub-and-Spoke in conjunction with seamless MPLS multicast [MPLS-MCAST] is outside the scope of this document.
シームレスMPLSマルチキャスト[MPLS-MCAST]と組み合わせた仮想HUBおよびスポークの使用は、このドキュメントの範囲外です。
We will speak of a P-tunnel being "bound" to a particular I-PMSI/S-PMSI A-D route if the P-tunnel is specified in that route's PMSI Tunnel attribute.
特定のI-PMSI / S-PMSI A-DルートにPトンネルが指定されている場合、そのルートのPMSIトンネル属性でPトンネルが「バインド」されていることを説明します。
When Ingress Replication is used, the P-tunnel bound to a particular I-PMSI/S-PMSI A-D route is actually a set of unicast tunnels (procedures differ from [RFC6514] for the case of I-PMSI and are specified in Section 7.9 of this document). The PE originating the I-PMSI/S-PMSI A-D route uses these unicast tunnels to carry traffic to the PEs that import the route. The PEs that import the route advertise labels for the unicast tunnels in Leaf A-D routes originated in response to the I-PMSI/S-PMSI A-D route. When we say that traffic has been received by a PE on a P-tunnel "bound" to a particular I-PMSI/S-PMSI A-D route imported by that PE, we refer to the unicast tunnel for which the label was advertised in a Leaf A-D route by the PE that imported the I-PMSI/S-PMSI route; the PE that originated that route uses this tunnel to send traffic to the PE that imported the I-PMSI/S-PMSI route.
Ingress Replicationが使用される場合、特定のI-PMSI / S-PMSI ADルートにバインドされたPトンネルは、実際にはユニキャストトンネルのセットです（手順はI-PMSIの場合の[RFC6514]とは異なり、セクション7.9で指定されています）このドキュメントの）。 I-PMSI / S-PMSI A-Dルートを発信するPEは、これらのユニキャストトンネルを使用して、ルートをインポートするPEにトラフィックを伝送します。ルートをインポートするPEは、I-PMSI / S-PMSI A-Dルートへの応答として発信されたリーフA-Dルートのユニキャストトンネルのラベルをアドバタイズします。トラフィックが、そのPEによってインポートされた特定のI-PMSI / S-PMSI ADルートに「バインドされた」Pトンネル上のPEによって受信されたと言う場合、ラベルがアドバタイズされたユニキャストトンネルを参照します。 I-PMSI / S-PMSIルートをインポートしたPEによるリーフADルート。そのルートを発信したPEは、このトンネルを使用して、I-PMSI / S-PMSIルートをインポートしたPEにトラフィックを送信します。
On a V-spoke, the set of Eligible UMH routes consists of all the unicast VPN-IP routes received by the V-spoke, including the default VPN-IP routes received from its V-hub(s). Note that such routes MAY include routes received from other V-spokes. The routes received from other V-spokes could be either "vanilla" VPN-IP routes (routes using the IPv4 or IPv6 Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) set to 128 "MPLS-labeled VPN address" [IANA-SAFI]) or routes using the IPv4 or IPv6 AFI (as appropriate) but with the SAFI set to SAFI 129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI].
Vスポークでは、適格なUMHルートのセットは、Vハブから受信したデフォルトのVPN-IPルートを含む、Vスポークによって受信されたすべてのユニキャストVPN-IPルートで構成されます。このようなルートには、他のVスポークから受信したルートが含まれる場合があります。他のVスポークから受信したルートは、「バニラ」VPN-IPルート（128に設定されたIPv4またはIPv6アドレスファミリ識別子（AFI）および後続アドレスファミリ識別子（SAFI）を使用するルート）のいずれかである可能性があります[MPLSラベル付きVPNアドレス] [ IANA-SAFI]）またはIPv4またはIPv6 AFI（必要に応じて）を使用してルーティングしますが、SAFIをSAFI 129 "BGP / MPLS IP仮想プライベートネットワーク（VPN）のマルチキャスト" [IANA-SAFI]に設定します。
The default VPN-IP routes received from the V-hub(s) may be either Internet default VPN-IP routes or non-Internet default VPN-IP routes.
Vハブから受信したデフォルトのVPN-IPルートは、インターネットのデフォルトVPN-IPルートまたはインターネット以外のデフォルトVPN-IPルートのいずれかです。
When originating a VPN-IP default route, a V-hub, in addition to following the procedures specified in Section 3, also follows the procedures specified in Sections 6 and 7 of [RFC6514] (see also Section 5.1 of [RFC6513]). Specifically, the V-hub MUST add the VRF Route Import Extended Community that embeds the V-hub's IP address. The route also MUST include the Source AS extended community.
VPN-IPデフォルトルートを発信する場合、Vハブは、セクション3で指定された手順に加えて、[RFC6514]のセクション6および7で指定された手順も実行します（[RFC6513]のセクション5.1も参照）。具体的には、Vハブは、VハブのIPアドレスを埋め込むVRFルートインポート拡張コミュニティを追加する必要があります。ルートには、ソースAS拡張コミュニティも含める必要があります。
In the following, the term "C-multicast routes" refers to BGP routes that carry customer multicast routing information [RFC6514].
以下では、「Cマルチキャストルート」という用語は、顧客のマルチキャストルーティング情報を運ぶBGPルートを指します[RFC6514]。
Origination of C-multicast routes follows the procedures specified in [RFC6514] (irrespective of whether these routes are originated by a V-hub or a V-spoke).
Cマルチキャストルートの発信は、[RFC6514]で指定された手順に従います（これらのルートがVハブまたはVスポークのどちらから発信されたかに関係なく）。
When a V-spoke receives a C-multicast route, the V-spoke follows the procedures described in [RFC6514].
VスポークがCマルチキャストルートを受信すると、Vスポークは[RFC6514]で説明されている手順に従います。
When a V-hub receives a C-multicast route, the V-hub determines whether the customer Rendezvous Point (C-RP) or the customer source (C-S) of the route is reachable via one of its VRF interfaces; if yes, then the V-hub follows the procedures described in [RFC6514].
VハブがCマルチキャストルートを受信すると、Vハブは、ルートのカスタマーランデブーポイント（C-RP）またはカスタマーソース（C-S）がVRFインターフェイスの1つを介して到達可能かどうかを判断します。はいの場合、Vハブは[RFC6514]で説明されている手順に従います。
Otherwise, the C-RP/C-S of the route is reachable via some other PE (this is the case where the received route was originated by a V-spoke that sees the V-hub as the "upstream PE" for a given source, but the V-hub sees some other PE -- either V-hub or V-spoke -- as the "upstream PE" for that source). In this case, the V-hub uses the type (Source Tree Join vs Shared Tree Join), the Multicast Source, and Multicast Group from the received C-multicast route to construct a new route of the same type, with the same Multicast Source and Multicast Group. The hub constructs the rest of the new route following procedures specified in Section 11.1.3 of [RFC6514]. The hub also creates the appropriate (C-*, C-G) or (C-S, C-G) state in its MVPN Tree Information Base (MVPN-TIB).
それ以外の場合、ルートのC-RP / CSは他のPEを介して到達可能です（これは、受信されたルートが、Vハブを特定のソースの「上流PE」として認識するVスポークによって発信された場合です。ただし、Vハブは他のPE（VハブまたはVスポーク）をそのソースの「上流PE」として認識します。この場合、Vハブは、タイプ（ソースツリー結合と共有ツリー結合）、マルチキャストソース、および受信したCマルチキャストルートからのマルチキャストグループを使用して、同じマルチキャストソースを持つ同じタイプの新しいルートを構築します。およびマルチキャストグループ。ハブは、[RFC6514]のセクション11.1.3で指定された手順に従って、残りの新しいルートを構築します。ハブは、MVPNツリー情報ベース（MVPN-TIB）に適切な（C-*、C-G）または（C-S、C-G）状態も作成します。
When a V-spoke originates an I-PMSI, an S-PMSI, or Source Active (SA) A-D route, the V-spoke follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), including the procedures for constructing RT(s) carried by the route. Note that as a result, such a route will be imported by the V-hubs. In the case of an I-PMSI/S-PMSI A-D route, the P-tunnel bound to this route is used to carry to these V-hubs traffic originated by the sites connected to the V-spoke.
VスポークがI-PMSI、S-PMSI、またはソースアクティブ（SA）ADルートを発信する場合、Vスポークは[RFC6514]で指定された手順に従います（またはワイルドカードS-PMSI ADルートの場合） 、[RFC6625]で指定された手順）、ルートで運ばれるRTを構築する手順を含みます。その結果、そのようなルートはVハブによってインポートされることに注意してください。 I-PMSI / S-PMSI A-Dルートの場合、このルートにバインドされたPトンネルは、Vスポークに接続されたサイトから発信されたこれらのVハブトラフィックに伝送するために使用されます。
If the V-spoke exports its (unicast) VPN-IP routes not just to the V-hubs but also to some other V-spokes (as described in Section 3), then (as a result of following the procedures specified in [RFC6514] or, in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]) the I-PMSI/S-PMSI/SA A-D route originated by the V-spoke will be imported not just by the V-hubs but also by the other V-spokes. This is because in this scenario, the route will carry more than one RT; one of these RTs, RT-VPN, will result in importing the route by the V-hubs, while other RT(s) will result in importing the route by the V-spokes (the other RT(s) are the RT(s) that the V-spoke uses for importing the VPN-IP default route). In this case, the P-tunnel bound to this I-PMSI/S-PMSI A-D route is also used to carry traffic originated by the sites connected to the V-spoke that originates the route to these other V-spokes.
Vスポークがその（ユニキャスト）VPN-IPルートをVハブだけでなく他の一部のVスポークにもエクスポートする場合（セクション3で説明）、（[RFC6514 ]または、ワイルドカードのS-PMSI ADルートの場合、[RFC6625]で指定された手順）V-スポークから発信されたI-PMSI / S-PMSI / SA ADルートは、V-ハブだけでなく、他のVスポークによっても。これは、このシナリオでは、ルートが複数のRTを運ぶためです。これらのRTの1つであるRT-VPNは、Vハブによってルートをインポートしますが、他のRTはVスポークによってルートをインポートします（他のRTはRTです） ）V-spokeがVPN-IPデフォルトルートをインポートするために使用する）。この場合、このI-PMSI / S-PMSI A-DルートにバインドされたPトンネルは、他のVスポークへのルートを発信するVスポークに接続されたサイトによって発信されたトラフィックを運ぶためにも使用されます。
When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the V-hub follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), except that in addition to the RT(s) constructed following these procedures, the route MUST also carry the RT of the VPN-IP default route advertised by the V-hub (RT-VH). Note that as a result, such a route will be imported by other V-hubs and also by the V-spokes, but only by the V-spokes that are associated with the V-hub (the V-spokes that import the VPN-IP default route originated by the V-hub). In the case of an I-PMSI/S-PMSI A-D route, the P-tunnel bound to this route is used to carry to these other V-hubs and V-spokes the traffic originated by the sites connected to the V-hub that originates the route.
VハブがI-PMSI / S-PMSI / SA ADルートを発信する場合、Vハブは[RFC6514]で指定された手順に従います（またはワイルドカードS-PMSI ADルートの場合、[ RFC6625]）、ただし、これらの手順に従って構築されたRTに加えて、ルートはVハブ（RT-VH）によってアドバタイズされたVPN-IPデフォルトルートのRTも伝送する必要があります。その結果、このようなルートは他のVハブとVスポークによってインポートされますが、Vハブに関連付けられているVスポーク（VPNをインポートするVスポーク）のみがインポートすることに注意してくださいVハブから発信されたIPデフォルトルート）。 I-PMSI / S-PMSI ADルートの場合、このルートにバインドされたPトンネルは、これらの他のVハブとVスポークに伝送するために使用され、Vハブに接続されたサイトから発信されたトラフィックをVスポークします。ルートを開始します。
In addition, if a V-hub originates an I-PMSI A-D route following the procedures specified in [RFC6514], the V-hub MUST originate another I-PMSI A-D route -- we'll refer to this route as an "Associated-V-spoke-only I-PMSI A-D route". The RT carried by this route MUST be the RT that is carried in the VPN-IP default route advertised by the V-hub (RT-VH). Therefore, this route will be imported only by the V-spokes associated with the V-hub (the V-spokes that import the VPN-IP default route advertised by this V-hub). The P-tunnel bound to this route is used to carry to these V-spokes traffic originated by the sites connected to either (a) other V-hubs, (b) other V-spokes, including the V-spokes that import the VPN-IP default route from the V-hub, or (c) "vanilla" PEs.
さらに、[RFC6514]で指定された手順に従ってVハブがI-PMSI ADルートを発信する場合、Vハブは別のI-PMSI ADルートを発信する必要があります-このルートを「関連付けられた- VスポークのみのI-PMSI ADルート。このルートによって運ばれるRTは、Vハブ（RT-VH）によってアドバタイズされるVPN-IPデフォルトルートで運ばれるRTである必要があります。したがって、このルートは、Vハブに関連付けられたVスポーク（このVハブによってアドバタイズされるVPN-IPデフォルトルートをインポートするVスポーク）によってのみインポートされます。このルートにバインドされたPトンネルは、（a）他のVハブ、（b）VPNをインポートするVスポークを含む他のVスポークのいずれかに接続されたサイトから発信されたこれらのVスポークトラフィックに伝送するために使用されます-VハブからのIPデフォルトルート、または（c）「バニラ」PE。
More details on the use of this P-tunnel are described in Section 7.8.
このPトンネルの使用の詳細については、セクション7.8で説明します。
As a result, a V-hub originates not one, but two I-PMSI A-D routes -- one is a "vanilla" I-PMSI A-D route and another is an Associated-V-spoke-only I-PMSI A-D route. Each of these routes MUST have a distinct RD.
その結果、Vハブは1つではなく2つのI-PMSI A-Dルートを発信します。1つは「バニラ」I-PMSI A-Dルートで、もう1つは、関連付けられたVスポークのみのI-PMSI A-Dルートです。これらの各ルートには、個別のRDが必要です。
When a V-hub receives traffic from one of the sites connected to the V-hub, and the V-hub determines (using some local policies) that this traffic should be transmitted using an I-PMSI, the V-hub forwards this traffic on the P-tunnel bound to the "vanilla" I-PMSI A-D route but MUST NOT forward it on the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route.
VハブがVハブに接続されているサイトの1つからトラフィックを受信し、Vハブが（一部のローカルポリシーを使用して）このトラフィックをI-PMSIを使用して送信する必要があると判断すると、Vハブはこのトラフィックを転送します「バニラ」I-PMSI ADルートにバインドされたPトンネル上では、ただし、Associated-V-spoke-only I-PMSI ADルートにバインドされたPトンネル上では転送しないでください。
When a V-spoke receives an I-PMSI/S-PMSI/SA A-D route, the V-spoke follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]). As a result, a V-spoke that is associated with a given V-hub (the V-spoke that imports the VPN-IP default route originated by that V-hub) will also import I-PMSI/S-PMSI/SA A-D routes originated by that V-hub. Specifically, the V-spoke will import both the "vanilla" I-PMSI A-D route and the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
VスポークがI-PMSI / S-PMSI / SA ADルートを受信すると、Vスポークは[RFC6514]で指定された手順に従います（またはワイルドカードS-PMSI ADルートの場合、[ RFC6625]）。その結果、特定のVハブに関連付けられているVスポーク（そのVハブによって発信されたVPN-IPデフォルトルートをインポートするVスポーク）も、I-PMSI / S-PMSI / SA ADをインポートしますそのVハブから発信されたルート。具体的には、Vスポークは、「バニラ」I-PMSI A-Dルートと、Vハブが発信したAssociated-VスポークのみのI-PMSI A-Dルートの両方をインポートします。
In addition, if a V-spoke imports the (unicast) VPN-IP routes originated by some other V-spokes (as described in Section 3), then the V-spoke will also import I-PMSI/S-PMSI/SA A-D routes originated by these other V-spokes.
さらに、Vスポークが他の一部のVスポークから発信された（ユニキャスト）VPN-IPルートをインポートする場合（セクション3で説明）、VスポークはI-PMSI / S-PMSI / SA ADもインポートしますこれらの他のVスポークから発信されたルート。
The following describes procedures that a V-hub MUST follow when it receives an I-PMSI/S-PMSI/SA A-D route.
以下は、I-PMSI / S-PMSI / SA A-Dルートを受信したときにVハブが従わなければならない手順について説明しています。
This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D route, and one of the RT(s) carried in the route is the RT that the V-hub uses for advertising its VPN-IP default route (RT-VH).
これは、VハブがI-PMSI / S-PMSI / SA ADルートを受信し、ルートで運ばれるRTの1つが、VハブがVPN-IPのアドバタイズに使用するRTである場合です。デフォルトルート（RT-VH）。
In this case, the receiving route was originated either
この場合、受信ルートは次のいずれかから発信されました
+ by a V-spoke associated with the V-hub (the V-spoke that imports the VPN-IP default route originated by the V-hub), or
+ Vハブに関連付けられたVスポーク（Vハブから発信されたVPN-IPデフォルトルートをインポートするVスポーク）、または
+ by some other V-hub that uses the same RT as the receiving V-hub for advertising the VPN-IP default route.
+ VPN-IPデフォルトルートをアドバタイズするために受信Vハブと同じRTを使用する他のVハブによって。
In this case, the received I-PMSI/S-PMSI/SA A-D route carries more than one RT. One of these RTs results in importing this route by the V-hubs. Another of these RTs is the RT that the V-hub uses when advertising its VPN-IP default route (RT-VH). This RT results in importing the received I-PMSI/S-PMSI/SA A-D route by all the V-spokes associated with the V-hub (the V-spokes that import the VPN-IP default route originated by the V-hub).
この場合、受信したI-PMSI / S-PMSI / SA A-Dルートは複数のRTを伝送します。これらのRTの1つにより、Vハブによってこのルートがインポートされます。これらのRTのもう1つは、VハブがVPN-IPデフォルトルート（RT-VH）をアドバタイズするときに使用するRTです。このRTは、Vハブに関連付けられたすべてのVスポーク（Vハブによって発信されたVPN-IPデフォルトルートをインポートするVスポーク）によって、受信したI-PMSI / S-PMSI / SA ADルートをインポートします。 。
In handling such an I-PMSI/S-PMSI/SA A-D route, the V-hub simply follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]).
このようなI-PMSI / S-PMSI / SA ADルートを処理する場合、Vハブは[RFC6514]で指定された手順（またはワイルドカードS-PMSI ADルートの場合、[RFC6625]で指定された手順）に従うだけです。 ）。
Specifically, the V-hub MUST NOT reoriginate this route as done in Case 2 below.
具体的には、Vハブはこのルートを以下のケース2で行われるように再発信してはなりません（MUST NOT）。
The following specifies the rules that the V-hub MUST follow when handling traffic that the V-hub receives on a P-tunnel bound to this I-PMSI/S-PMSI A-D route. The V-hub may forward this traffic to only the sites connected to that V-hub (forwarding this traffic to these sites follows the procedures specified in [RFC6514] or, in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]). The V-hub MUST NOT forward the traffic received on this P-tunnel to any other V-hubs or V-spokes, including the V-spokes that import the VPN-IP default route originated by the V-hub (V-spokes associated with the V-hub). Specifically, the V-hub MUST NOT forward the traffic received on the P-tunnel advertised in the received I-PMSI A-D route over the P-tunnel that the V-hub binds to its Associated-V-spoke-only I-PMSI A-D route.
以下は、このI-PMSI / S-PMSI A-DルートにバインドされたPトンネルでVハブが受信するトラフィックを処理するときに、Vハブが従わなければならない規則を指定しています。 Vハブは、このトラフィックをそのVハブに接続されているサイトにのみ転送できます（これらのサイトへのトラフィックの転送は、[RFC6514]で指定された手順に従うか、ワイルドカードS-PMSI ADルートの場合は、指定された手順に従います[RFC6625]で）。 Vハブは、このPトンネルで受信したトラフィックを、他のVハブまたはVスポークに転送してはなりません。これには、Vハブによって発信されたVPN-IPデフォルトルートをインポートするVスポーク（Vスポークが関連付けられている）が含まれますVハブ）。具体的には、Vハブは、Vハブが関連付けられたVスポークのみのI-PMSI ADにバインドするPトンネルを介して、受信したI-PMSI ADルートでアドバタイズされたPトンネルで受信したトラフィックを転送してはなりません（MUST NOT）。ルート。
This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D route, and the route does not carry the RT that the receiving V-hub uses when advertising its VPN-IP default route (RT-VH).
これは、VハブがI-PMSI / S-PMSI / SA ADルートを受信し、そのルートが、VPN-IPデフォルトルート（RT-VH ）。
In this case, the receiving I-PMSI/S-PMSI/SA A-D route was originated by either some other V-hub or a V-spoke. The I-PMSI/S-PMSI/SA A-D route is imported by the V-hub (as well as by other V-hubs) but not by any of the V-spokes associated with the V-hub (V-spokes that import the VPN-IP default route originated by the V-hub).
この場合、受信側のI-PMSI / S-PMSI / SA A-Dルートは、他のVハブまたはVスポークによって発信されました。 I-PMSI / S-PMSI / SA ADルートは、Vハブ（および他のVハブ）によってインポートされますが、Vハブに関連付けられたVスポーク（インポートされるVスポーク）によってはインポートされません。 Vハブから発信されたVPN-IPデフォルトルート）。
In this case, the V-hubs follow the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), with the following additions.
この場合、Vハブは[RFC6514]で指定された手順（またはワイルドカードS-PMSI A-Dルートの場合、[RFC6625]で指定された手順）に以下の追加を加えたものに従います。
Once a V-hub accepts an I-PMSI A-D route, when the V-hub receives data on the P-tunnel bound to that I-PMSI A-D route, the V-hub follows the procedures specified in [RFC6513] and [RFC6514] to determine whether to accept the data. If the data is accepted, then the V-hub further forwards the data over the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub. Note that in deciding whether to forward the data over the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub, the V-hub SHOULD take into account the (multicast) state present in its MVPN-TIB that has been created as a result of receiving C-multicast routes from the V-spokes associated with the V-hub. If (using the information present in the MVPN-TIB) the V-hub determines that none of these V-spokes have receivers for the data, the V-hub SHOULD NOT forward the data over the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
VハブがI-PMSI ADルートを受け入れると、VハブがそのI-PMSI ADルートにバインドされたPトンネルでデータを受信すると、Vハブは[RFC6513]および[RFC6514]で指定された手順に従いますデータを受け入れるかどうかを決定します。データが受け入れられると、Vハブはさらに、Vハブによって発信されたAssociated-V-spoke-only I-PMSI A-DルートにバインドされたPトンネルを介してデータを転送します。 Vハブによって発信されたAssociated-V-spoke-only I-PMSI ADルートにバインドされたPトンネルを介してデータを転送するかどうかを決定する際、Vハブは、存在する（マルチキャスト）状態を考慮する必要があることに注意してくださいVハブに関連付けられたVスポークからCマルチキャストルートを受信した結果として作成されたMVPN-TIB内。 （MVPN-TIBに存在する情報を使用して）VハブがこれらのVスポークのいずれにもデータのレシーバーがないと判断した場合、Vハブは、関連付けられたVにバインドされたPトンネルを介してデータを転送しないでください（SHOULD NOT） -Vハブから発信されたスポークのみのI-PMSI ADルート。
Whenever a V-hub imports an S-PMSI A-D route (respectively, SA A-D route) in a VRF, the V-hub, in contrast to Case 1 above, MUST originate an S-PMSI A-D route (respectively, SA A-D route) targeted to its V-spokes. To accomplish this, the V-hub replaces the RT(s) carried in the route with the RT that the V-hub uses when originating its VPN-IP default route (RT-VH), changes the RD of the route to the RD that the V-hub uses when originating its Associated-V-spoke-only I-PMSI A-D route, and sets Next Hop to the IP address that the V-hub places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the V-hub. For S-PMSI A-D routes, the V-hub also changes the Originating Router's IP address in the MCAST-VPN NLRI (Network Layer Reachability Information) of the route to the same address as the one in the Next Hop. Moreover, before advertising the new S-PMSI A-D route, the V-hub modifies its PMSI Tunnel attribute as appropriate (e.g., by replacing the P-tunnel rooted at the originator of this route with a P-tunnel rooted at the V-hub).
VハブがVRFにS-PMSI ADルート（それぞれ、SA ADルート）をインポートするときは常に、Vハブは、上記のケース1とは対照的に、S-PMSI ADルート（それぞれ、SA ADルート）を作成する必要があります。 Vスポークをターゲットにしています。これを達成するために、Vハブは、ルートで運ばれるRTを、VハブがそのVPN-IPデフォルトルート（RT-VH）を発信するときに使用するRTに置き換え、ルートのRDをRDに変更します関連付けられたVスポークのみのI-PMSI ADルートを発信するときにVハブが使用し、VハブがVRFルートインポート拡張コミュニティのグローバルアドミニストレーターフィールドのグローバルアドミニストレーターフィールドに配置するIPアドレスに次ホップを設定します。 VハブによってアドバタイズされるVPN-IPルート。 S-PMSI A-Dルートの場合、Vハブは、ルートのMCAST-VPN NLRI（ネットワーク層到達可能性情報）の発信元ルーターのIPアドレスも、ネクストホップのアドレスと同じアドレスに変更します。さらに、新しいS-PMSI ADルートをアドバタイズする前に、VハブはそのPMSIトンネル属性を適切に変更します（たとえば、このルートの発信者をルートとするPトンネルをVハブをルートとするPトンネルに置き換えることにより） ）。
Note that a V-hub of a given MVPN may receive and accept multiple (C-*, C-*) wildcard S-PMSI A-D routes [RFC6625], each originated by its own PE. Yet, even if the V-hub receives and accepts such multiple (C-*, C-*) S-PMSI A-D routes, the V-hub re-advertises just one (C-*, C-*) S-PMSI A-D route, thus aggregating the received (C-*, C-*) S-PMSI A-D routes. The same applies for (C-*, C-G) S-PMSI A-D routes.
特定のMVPNのVハブが複数の（C-*、C- *）ワイルドカードS-PMSI A-Dルート[RFC6625]を受信して受け入れる場合があることに注意してください。ただし、Vハブがそのような複数の（C-*、C- *）S-PMSI ADルートを受信して受け入れる場合でも、Vハブは1つだけ（C-*、C- *）S-PMSI ADを再アドバタイズしますルート、つまり受信した（C-*、C- *）S-PMSI ADルートを集約します。 （C-*、C-G）S-PMSI A-Dルートにも同じことが適用されます。
Whenever a V-hub receives data on the P-tunnel bound to a received S-PMSI A-D route, the V-hub follows the procedures specified in [RFC6513] and [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]) to determine whether to accept the data. If the data is accepted, then the V-hub further forwards it over the P-tunnel bound to the S-PMSI A-D route that has been re-advertised by the V-hub.
Vハブは、受信したS-PMSI ADルートにバインドされたPトンネルでデータを受信するたびに、[RFC6513]および[RFC6514]で指定された手順に従います（またはワイルドカードS-PMSI ADの場合）ルート、[RFC6625]で指定された手順）データを受け入れるかどうかを決定します。データが受け入れられると、Vハブはさらに、Vハブによって再アドバタイズされたS-PMSI A-DルートにバインドされたPトンネルを介してデータを転送します。
If multiple S-PMSIs received by a V-hub have been aggregated into the same P-tunnel, then the V-hub, prior to forwarding to the V-spokes associated with that V-hub the data received on this P-tunnel, MAY de-aggregate and then reaggregate (in a different way) this data using the state present in its MVPN-TIB that has been created as a result of receiving C-multicast routes from the V-spokes. Even if S-PMSIs received by the V-hub each have their own P-tunnel, the V-hub, prior to forwarding to the V-spokes the data received on these P-tunnels, MAY aggregate these S-PMSIs using the state present in its MVPN-TIB that has been created as a result of receiving C-multicast routes from the V-spokes.
Vハブによって受信された複数のS-PMSIが同じPトンネルに集約されている場合、Vハブは、そのVハブに関連付けられたVスポークに転送する前に、このPトンネルで受信したデータ、 VスポークからCマルチキャストルートを受信した結果として作成されたMVPN-TIBに存在する状態を使用して、このデータを（別の方法で）集約解除してから再集約できます（MAY）。 Vハブによって受信されたS-PMSIにそれぞれ独自のPトンネルがある場合でも、Vハブは、これらのPトンネルで受信されたデータをVスポークに転送する前に、状態を使用してこれらのS-PMSIを集約できます（MAY） VスポークからCマルチキャストルートを受信した結果として作成されたMVPN-TIBに存在します。
The following modifications to the procedures specified in [RFC6514] for originating/receiving I-PMSI A-D routes enable the discarding of packets coming from a "wrong" PE when Ingress Replication is used for I-PMSI P-tunnels (for other types of P-tunnels, the procedures specified in [RFC6513] and [RFC6514] are sufficient).
[RFC6514]で指定されているI-PMSI ADルートの発信/受信手順に対する次の変更により、I-PMSI Pトンネル（他のタイプのPの場合）にIngress Replicationが使用されている場合、「間違った」PEからのパケットを破棄できます-トンネル、[RFC6513]および[RFC6514]で指定された手順で十分です）。
The modifications to the procedures are required to be implemented (by all the PEs of a given MVPN) only under the following conditions:
手順の変更は、次の条件下でのみ（特定のMVPNのすべてのPEによって）実装する必要があります。
+ At least one of those PEs is a V-hub or V-spoke PE for the given MVPN.
+ それらのPEの少なくとも1つは、特定のMVPNのVハブまたはVスポークPEです。
+ The given MVPN is configured to use the optional procedure of using Ingress Replication to instantiate an I-PMSI.
+ 特定のMVPNは、入力レプリケーションを使用してI-PMSIをインスタンス化するオプションの手順を使用するように設定されています。
If Ingress Replication is used with I-PMSI A-D routes, when a PE advertises such routes, the Tunnel Type in the PMSI Tunnel attribute MUST be set to Ingress Replication; the Leaf Information Required flag MUST be set to 1; the attribute MUST carry no MPLS labels.
入力レプリケーションがI-PMSI A-Dルートで使用される場合、PEがそのようなルートをアドバタイズするとき、PMSIトンネル属性のトンネルタイプは入力レプリケーションに設定する必要があります。 Leaf Information Requiredフラグは1に設定する必要があります。属性はMPLSラベルを持たない必要があります。
A PE that receives such an I-PMSI A-D route MUST respond with a Leaf A-D route. The PMSI Tunnel attribute of that Leaf A-D route is constructed as follows:
そのようなI-PMSI A-Dルートを受信するPEは、リーフA-Dルートで応答する必要があります。そのリーフA-DルートのPMSIトンネル属性は、次のように構成されます。
o The Tunnel Type is set to Ingress Replication.
o Tunnel TypeはIngress Replicationに設定されています。
o The Tunnel Identifier MUST carry a routable address of the PE that originates the Leaf A-D route.
o トンネル識別子は、リーフA-Dルートを発信するPEのルーティング可能なアドレスを運ぶ必要があります。
o The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used to demultiplex the traffic received over a unicast tunnel by the PE.
o PMSIトンネル属性は、PEによってユニキャストトンネルを介して受信されたトラフィックを逆多重化するために使用されるダウンストリーム割り当てMPLSラベルを運ぶ必要があります。
o The receiving PE MUST assign the label in such a way as to enable the receiving PE to identify (a) the VRF on that PE that should be used to process the traffic received with this label and (b) the PE that sends the traffic with this label.
o 受信側PEは、受信側PEが（a）このラベルで受信したトラフィックの処理に使用する必要があるそのPE上のVRFおよび（b）トラフィックを送信するPEを識別できるようにラベルを割り当てなければなりません（MUST）。このラベル。
This document assumes that for a given MVPN, all the PEs that have sites of that MVPN connected to them implement the procedures specified in this section.
このドキュメントでは、特定のMVPNについて、そのMVPNのサイトが接続されているすべてのPEが、このセクションで指定された手順を実装すると想定しています。
Consider a VPN A that consists of 9 sites -- site-1 through site-9. Each site is connected to its own PE -- PE-1 through PE-9.
サイト1からサイト9までの9つのサイトで構成されるVPN Aについて考えます。各サイトは独自のPE-PE-1からPE-9に接続されています。
We designate PE-3, PE-6, and PE-9 as V-hubs.
PE-3、PE-6、およびPE-9をVハブとして指定します。
To simplify the presentation, the following example assumes that each V-spoke is associated with just one V-hub. However, as mentioned earlier, in practice each V-spoke should be associated with two or more V-hubs.
プレゼンテーションを簡略化するために、次の例では、各Vスポークが1つのVハブにのみ関連付けられていると想定しています。ただし、前述のように、実際には各Vスポークは2つ以上のVハブに関連付ける必要があります。
PE-1 and PE-2 are V-spokes associated with PE-3. PE-4 and PE-5 are V-spokes associated with PE-6. PE-7 and PE-8 are V-spokes associated with PE-9.
PE-1およびPE-2は、PE-3に関連付けられたVスポークです。 PE-4およびPE-5は、PE-6に関連付けられたVスポークです。 PE-7およびPE-8は、PE-9に関連付けられたVスポークです。
All the PEs (both V-hubs and V-spokes) are provisioned to export routes using RT-A (just as with "vanilla" any-to-any VPN).
すべてのPE（VハブとVスポークの両方）は、RT-Aを使用してルートをエクスポートするようにプロビジョニングされます（「バニラ」のAny-to-Any VPNと同様）。
All the V-hubs (PE-3, PE-6, and PE-9) are provisioned to import routes with RT-A (just as with "vanilla" any-to-any VPN).
すべてのVハブ（PE-3、PE-6、およびPE-9）は、RT-Aを使用してルートをインポートするようにプロビジョニングされます（「バニラ」のAny-to-Any VPNと同様に）。
In addition, PE-3 is provisioned to originate a VPN-IP default route with RT-A-VH-1 (but not with RT-A), while PE-1 and PE-2 are provisioned to import routes with RT-A-VH-1.
さらに、PE-3はRT-A-VH-1（RT-Aではない）でVPN-IPデフォルトルートを発信するようにプロビジョニングされていますが、PE-1およびPE-2はRT-Aでルートをインポートするようにプロビジョニングされています-VH-1。
Likewise, PE-6 is provisioned to originate a VPN-IP default route with RT-A-VH-2 (but not with RT-A), while PE-4 and PE-5 are provisioned to import routes with RT-A-VH-2.
同様に、PE-6はRT-A-VH-2（RT-Aではない）でVPN-IPデフォルトルートを発信するようにプロビジョニングされていますが、PE-4およびPE-5はRT-A-でルートをインポートするようにプロビジョニングされていますVH-2。
Finally, PE-9 is provisioned to originate a VPN-IP default route with RT-A-VH-3 (but not with RT-A), while PE-7 and PE-8 are provisioned to import routes with RT-A-VH-3.
最後に、PE-9は、RT-A-VH-3（RT-Aではない）でVPN-IPデフォルトルートを発信するようにプロビジョニングされ、PE-7およびPE-8は、RT-A- VH-3。
Now let's modify the example above a bit by assuming that site-3 has Internet connectivity. Thus, site-3 advertises an IP default route to PE-3. PE-3 in turn originates a VPN-IP default route. In this case, the VPN-IP default route carries RT-A and RT-A-VH-1 (rather than just RT-A-VH-1, as before), which results in importing this route to PE-6 and PE-9, as well as to PE-1 and PE-2.
次に、サイト3がインターネットに接続していると想定して、上記の例を少し変更します。したがって、サイト3はIPデフォルトルートをPE-3にアドバタイズします。 PE-3は、VPN-IPデフォルトルートを発信します。この場合、VPN-IPのデフォルトルートは、RT-AおよびRT-A-VH-1を（以前のRT-A-VH-1だけでなく）運ぶため、このルートがPE-6およびPEにインポートされます。 -9、およびPE-1とPE-2。
If PE-7 and PE-8, in addition to importing a VPN-IP default route from PE-9, also want to import each other's VPN-IP routes, then PE-7 and PE-8 export their VPN-IP routes with two RTs: RT-A and RT-A-VH-3.
PE-9からのVPN-IPデフォルトルートのインポートに加えて、PE-7とPE-8が互いのVPN-IPルートもインポートする場合、PE-7とPE-8は次のコマンドでVPN-IPルートをエクスポートします。 2つのRT：RT-AおよびRT-A-VH-3。
All the PEs designated as V-spokes (PE-1, PE-2, PE-4, PE-5, PE-7, and PE-8) are provisioned to export their I-PMSI/S-PMSI/SA A-D routes using RT-A (just as with "vanilla" any-to-any MVPN). Thus, these routes could be imported by all the V-hubs (PE-3, PE-6, and PE-9).
Vスポークとして指定されたすべてのPE（PE-1、PE-2、PE-4、PE-5、PE-7、およびPE-8）は、それらのI-PMSI / S-PMSI / SA ADルートをエクスポートするためにプロビジョニングされますRT-Aを使用する（「バニラ」any-to-any MVPNと同様）。したがって、これらのルートはすべてのVハブ（PE-3、PE-6、およびPE-9）でインポートできます。
The V-hub on PE-3 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-1. Thus, these routes could be imported by all the other V-hubs (PE-6 and PE-9) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-3 (PE-1 and PE-2). In addition, the V-hub on PE-3 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-1. This route could be imported only by the V-spokes associated with the V-hub on PE-3 (PE-1 and PE-2).
PE-3のVハブは、RT-AとRT-A-VH-1の2つのRTを持つI-PMSI / S-PMSI / SA A-Dルートをエクスポートするようにプロビジョニングされています。したがって、これらのルートは、他のすべてのVハブ（PE-6およびPE-9）とVスポークによってインポートできますが、PE-3（PEのVハブに関連付けられているVスポークのみがインポートできます。 -1およびPE-2）。さらに、PE-3のVハブは、RT-A-VH-1を使用して、Associated-V-spoke-only I-PMSI A-Dルートを発信します。このルートは、PE-3（PE-1およびPE-2）のVハブに関連付けられたVスポークによってのみインポートできます。
The V-hub on PE-6 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-2. Thus, these routes could be imported by all the other V-hubs (PE-3 and PE-9) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-6 (PE-4 and PE-5). In addition, the V-hub on PE-6 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-2. This route could be imported only by the V-spokes associated with the V-hub on PE-6 (PE-4 and PE-5).
PE-6のVハブは、RT-AとRT-A-VH-2の2つのRTを持つI-PMSI / S-PMSI / SA A-Dルートをエクスポートするようにプロビジョニングされています。したがって、これらのルートは、他のすべてのVハブ（PE-3およびPE-9）とVスポークによってインポートできますが、PE-6（PEのVハブに関連付けられているVスポークのみがインポートできます。 -4およびPE-5）。さらに、PE-6のVハブは、RT-A-VH-2を使用して、Associated-V-spoke-only I-PMSI A-Dルートを発信します。このルートは、PE-6（PE-4およびPE-5）のVハブに関連付けられたVスポークによってのみインポートできます。
The V-hub on PE-9 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-3. Thus, these routes could be imported by all the other V-hubs (PE-3 and PE-6) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8). In addition, the V-hub on PE-9 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-3. This route could be imported only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8).
PE-9のVハブは、RT-AとRT-A-VH-3の2つのRTを持つI-PMSI / S-PMSI / SA A-Dルートをエクスポートするようにプロビジョニングされています。したがって、これらのルートは、他のすべてのVハブ（PE-3およびPE-6）とVスポークによってインポートできますが、PE-9（PEのVハブに関連付けられたVスポークのみがインポートできます。 -7およびPE-8）。さらに、PE-9のVハブは、RT-A-VH-3を使用して、Associated-V-spoke-only I-PMSI A-Dルートを発信します。このルートは、PE-9（PE-7およびPE-8）のVハブに関連付けられたVスポークによってのみインポートできます。
If PE-7 and PE-8, in addition to importing a VPN-IP default route from PE-9, also want to import each other's VPN-IP routes, then PE-7 and PE-8 export their I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-3.
PE-7とPE-8が、PE-9からのVPN-IPデフォルトルートのインポートに加えて、互いのVPN-IPルートもインポートする場合、PE-7とPE-8はI-PMSI / Sをエクスポートします。 -2つのRTを持つPMSI / SA ADルート：RT-AとRT-A-VH-3。
If the V-hub on PE-9 imports an S-PMSI A-D route or SA A-D route originated by either some other V-hub (PE-3 or PE-6) or a V-spoke that is not associated with this V-hub (PE-1, or PE-2, or PE-4, or PE-5), the V-hub originates an S-PMSI A-D route (respectively, SA A-D route). The V-hub constructs this route from the imported route following the procedures specified in Section 7.8.2. Specifically, the V-hub replaces the RT(s) carried in the imported route with just one RT -- RT-A-VH-3. Thus, the originated route could be imported only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8).
PE-9のVハブが他のVハブ（PE-3またはPE-6）またはこのV-に関連付けられていないV-スポークから発信されたS-PMSI ADルートまたはSA ADルートをインポートする場合ハブ（PE-1、またはPE-2、またはPE-4、またはPE-5）の場合、VハブはS-PMSI ADルート（それぞれ、SA ADルート）を発信します。 Vハブは、セクション7.8.2で指定された手順に従って、インポートされたルートからこのルートを構築します。具体的には、Vハブはインポートされたルートで運ばれるRTを1つのRT-RT-A-VH-3に置き換えます。したがって、発信ルートは、PE-9（PE-7およびPE-8）のVハブに関連付けられたVスポークによってのみインポートできます。
In some cases, a VPN customer may not want to rely solely on an (IP) default route being advertised from a V-spoke to a CE, but may want CEs to receive all the VPN routes (e.g., for the purpose of faster detection of VPN connectivity failures and activating some backup connectivity).
場合によっては、VPNカスタマーは、VスポークからCEにアドバタイズされる（IP）デフォルトルートのみに依存するのではなく、CEがすべてのVPNルートを受信することを望んでいる場合があります（たとえば、より迅速な検出のため）。 VPN接続の失敗と一部のバックアップ接続のアクティブ化）。
In this case, an OPTIONAL approach would be to install in the V-spoke's data plane only the VPN-IP default route advertised by the V-hub associated with the V-spoke, even if the V-spoke receives an IP default route from the CE, and to keep all the VPN-IP routes in the V-spoke's control plane (thus being able to advertise these routes as IP routes from the V-spoke to the CEs). Granted, this would not change control-plane resource consumption but would reduce forwarding state on the data plane.
この場合、オプションのアプローチは、VスポークがIPデフォルトルートを受信した場合でも、Vスポークに関連付けられたVハブによってアドバタイズされたVPN-IPデフォルトルートのみをVスポークのデータプレーンにインストールすることです。 CE、およびすべてのVPN-IPルートをVスポークのコントロールプレーンに保持します（したがって、これらのルートをVスポークからCEへのIPルートとしてアドバタイズできます）。確かに、これはコントロールプレーンのリソース消費を変更しませんが、データプレーンの転送状態を減らします。
This document introduces no new security considerations above and beyond those already specified in [RFC4364].
このドキュメントでは、[RFC4364]ですでに指定されているセキュリティ上の考慮事項以外に、新しいセキュリティ上の考慮事項は紹介されていません。
We would like to acknowledge Han Nguyen (AT&T) for his contributions to this document. We would like to thank Eric Rosen (Cisco) for his review and comments. We would also like to thank Samir Saad (AT&T), Jeffrey (Zhaohui) Zhang (Juniper), and Thomas Morin (Orange) for their review and comments.
このドキュメントへの貢献に対して、Han Nguyen（AT＆T）に感謝します。 Eric Rosen（Cisco）のレビューとコメントに感謝します。また、レビューとコメントをいただいたSamir Saad（AT＆T）、Jeffrey（Zhaohui）Zhang（Juniper）、Thomas Morin（Orange）にも感謝いたします。
[IANA-SAFI] IANA Subsequent Address Family Identifiers (SAFI) Parameters, <http://www.iana.org/assignments/safi-namespace/>.
[IANA-SAFI] IANA Subsequent Address Family Identifiers（SAFI）パラメータ、<http://www.iana.org/assignments/safi-namespace/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[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.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、February 2012。
[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.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、2012年2月。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR. Qiu、「Wildcards in Multicast VPN Auto-Discovery Routes」、RFC 6625、2012年5月。
[MPLS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Segmented LSPs", Work in Progress, May 2013.
[MPLS-MCAST] Rekhter、Y.、Aggarwal、R.、Morin、T.、Grosclaude、I.、Leymann、N。、およびS. Saad、「Inter-Area P2MP Segmented LSPs」、Work in Progress、2013年5月。
Authors' Addresses
著者のアドレス
Huajin Jeng AT&T
Huajin Ms. AT＆T
EMail: hj2387@att.com
James Uttaro AT&T
James Uttaro AT＆T
EMail: ju1738@att.com
Luay Jalil Verizon
ルアイ・ジャリル・ベライゾン
EMail: luay.jalil@verizon.com
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
EMail: bruno.decraene@orange.com
Yakov Rekhter Juniper Networks, Inc.
Yakov Rekhter Juniper Networks、Inc.
EMail: yakov@juniper.net
Rahul Aggarwal Arktan
ラフル・アガーワル・アークタン
EMail: raggarwa_1@yahoo.com