[要約] RFC 7716は、BGP-MVPN手順に関するグローバルテーブルマルチキャストについての要約です。このRFCの目的は、BGP-MVPNを使用してグローバルネットワークでマルチキャストをサポートするための手順を提供することです。
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7716 L. Giuliano
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
K. Subramanian
Cisco Systems, Inc.
D. Pacella
Verizon
December 2015
Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
BGPマルチキャストVPNを使用したグローバルテーブルマルチキャスト（BGP-MVPN）の手順
Abstract
概要
RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.
RFC 6513、6514、およびその他は、顧客にマルチキャスト仮想プライベートネットワーク（マルチキャストVPNまたはMVPN）サービスを提供するためにサービスプロバイダー（SP）が展開できるプロトコルと手順について説明しています。これらの手順の一部は、BGPを使用して、VPN固有のマルチキャストルーティング情報をバックボーンネットワーク全体に配信します。少数の比較的小さな変更により、同じBGP手順を使用して、VPNに固有ではないマルチキャストルーティング情報を配信することもできます。 VPNのコンテキスト外にあるマルチキャストは、「グローバルテーブルマルチキャスト」または「インターネットマルチキャスト」と呼ばれることもあります。このドキュメントでは、グローバルテーブルマルチキャストのBGP-MVPN手順を使用するために必要な変更について説明します。
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/rfc7716.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7716で入手できます。
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
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9
2.3.3. Non-BGP Routes as the UMH-Eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-Multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from Other MVPN-Like GTM Procedures . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
[RFC4364] specifies architecture, protocols, and procedures that a Service Provider (SP) can use to provide Virtual Private Network (VPN) service to its customers. In that architecture, one or more Customer Edge (CE) routers attach to a Provider Edge (PE) router. Each CE router belongs to a single VPN, but CE routers from several VPNs may attach to the same PE router. In addition, CEs from the same VPN may attach to different PEs. BGP is used to carry VPN-specific information among the PEs. Each PE router maintains a separate Virtual Routing and Forwarding table (VRF) for each VPN to which it is attached.
[RFC4364]は、サービスプロバイダー（SP）が顧客に仮想プライベートネットワーク（VPN）サービスを提供するために使用できるアーキテクチャ、プロトコル、および手順を指定しています。そのアーキテクチャでは、1つ以上のカスタマーエッジ（CE）ルーターがプロバイダーエッジ（PE）ルーターに接続します。各CEルーターは単一のVPNに属していますが、複数のVPNのCEルーターが同じPEルーターに接続する場合があります。さらに、同じVPNのCEが異なるPEに接続する場合があります。 BGPは、PE間でVPN固有の情報を伝送するために使用されます。各PEルータは、接続されているVPNごとに個別の仮想ルーティングおよび転送テーブル（VRF）を維持します。
[RFC6513] and [RFC6514] extend the procedures of [RFC4364] to allow the SP to provide multicast service to its VPN customers. The customer's multicast routing protocol (e.g., PIM) is used to exchange multicast routing information between a CE and a PE. The PE stores a given customer's multicast routing information in the VRF for that customer's VPN. BGP is used to distribute certain multicast-related control information among the PEs that attach to a given VPN, and BGP may also be used to exchange the customer multicast routing information itself among the PEs.
[RFC6513]と[RFC6514]は、[RFC4364]の手順を拡張して、SPがVPNカスタマーにマルチキャストサービスを提供できるようにします。カスタマーのマルチキャストルーティングプロトコル（PIMなど）は、CEとPEの間でマルチキャストルーティング情報を交換するために使用されます。 PEは、特定のカスタマーのマルチキャストルーティング情報を、そのカスタマーのVPNのVRFに保存します。 BGPは、特定のVPNに接続するPE間で特定のマルチキャスト関連の制御情報を配布するために使用されます。また、BGPは、PE間で顧客のマルチキャストルーティング情報自体を交換するためにも使用できます。
While this multicast architecture was originally developed for VPNs, it can also be used (with a small number of modifications to the procedures) to distribute multicast routing information that is not specific to VPNs. The purpose of this document is to specify the way in which BGP-MVPN procedures can be adapted to support non-VPN multicast.
このマルチキャストアーキテクチャはもともとVPN用に開発されましたが、VPNに固有ではないマルチキャストルーティング情報を配信するために（手順を少し変更するだけで）使用することもできます。このドキュメントの目的は、非VPNマルチキャストをサポートするためにBGP-MVPN手順を適合させる方法を指定することです。
Multicast routing information that is not specific to VPNs is stored in a router's "global table", rather than in a VRF; hence, it is known as "Global Table Multicast" (GTM). GTM is sometimes more simply called "Internet multicast". However, we will avoid that term because it suggests that the multicast data streams are available on the "public" Internet. The procedures for GTM can certainly be used to support multicast on the public Internet, but they can also be used to support multicast streams that are not public, e.g., content distribution streams offered by content providers to paid subscribers. For the purposes of this document, all that matters is that the multicast routing information is maintained in a global table rather than in a VRF.
VPNに固有ではないマルチキャストルーティング情報は、VRFではなく、ルータの「グローバルテーブル」に格納されます。したがって、「グローバルテーブルマルチキャスト」（GTM）として知られています。 GTMは「インターネットマルチキャスト」と呼ばれることもあります。ただし、マルチキャストデータストリームが「パブリック」インターネットで利用できることを示唆しているため、この用語は避けます。 GTMの手順は、公衆インターネットでのマルチキャストのサポートに使用できますが、コンテンツプロバイダーが有料加入者に提供するコンテンツ配信ストリームなど、パブリックではないマルチキャストストリームのサポートにも使用できます。このドキュメントの目的で重要なのは、マルチキャストルーティング情報がVRFではなくグローバルテーブルで維持されることです。
This architecture does assume that the network over which the multicast streams travel can be divided into a "core network" and one or more non-core parts of the network, which we shall call "attachment networks". The multicast routing protocol used in the attachment networks may not be the same as the one used in the core, so we consider there to be a "protocol boundary" between the core network and the attachment networks. We will use the term "Protocol Boundary Router" (PBR) to refer to the core routers that are at the boundary. We will use the term "Attachment Router" (AR) to refer to the routers that attach to the PBRs but are not in the core.
このアーキテクチャは、マルチキャストストリームが移動するネットワークを「コアネットワーク」と、ネットワークの1つ以上の非コア部分（「アタッチメントネットワーク」と呼ぶ）に分割できることを前提としています。アタッチメントネットワークで使用されるマルチキャストルーティングプロトコルは、コアで使用されるものとは異なる場合があるため、コアネットワークとアタッチメントネットワークの間に「プロトコル境界」があると見なします。 「プロトコル境界ルーター」（PBR）という用語を使用して、境界にあるコアルーターを指します。 「アタッチメントルーター」（AR）という用語は、PBRに接続するがコアにはないルーターを指すために使用します。
This document does not make any particular set of assumptions about the protocols that the ARs and the PBRs use to exchange unicast and multicast routing information with each other. For instance, multicast routing information could be exchanged between an AR and a PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an exchange of routes that are used for looking up the path to the root of a multicast tree. This routing information could be exchanged between an AR and a PBR via IGP, via EBGP, or via IBGP [RFC6368]. Note that if IBGP is used, the "push" and "pop" procedures described in [RFC6368] are not necessary.
このドキュメントでは、ARとPBRがユニキャストとマルチキャストのルーティング情報を相互に交換するために使用するプロトコルについて、特定の一連の仮定は行いません。たとえば、マルチキャストルーティング情報は、PIM、IGMP、またはBGPを介してARとPBRの間で交換できます。マルチキャストルーティングは、マルチキャストツリーのルートへのパスを検索するために使用されるルートの交換にも依存します。このルーティング情報は、IGP、EBGP、またはIBGP [RFC6368]を介してARとPBRの間で交換できます。 IBGPが使用される場合、[RFC6368]で説明されている「プッシュ」および「ポップ」手順は不要であることに注意してください。
The PBRs are not necessarily "edge routers", in the sense of [RFC4364]. For example, they may be both be Autonomous System Border Routers (ASBRs). As another example, an AR may be an "access router" attached to a PBR that is an OSPF Area Border Router (ABR). Many other deployment scenarios are possible. However, the PBRs are always considered to be delimiting a "backbone" or "core" network. A multicast data stream from an AR is tunneled over the core network from an ingress PBR to one or more egress PBRs. Multicast routing information that a PBR learns from the ARs attached to it is stored in the PBR's global table. The PBRs use BGP to distribute multicast routing and auto-discovery information among themselves. This is done following the procedures of [RFC6513], [RFC6514], and other MVPN specifications, as modified in this document.
[RFC4364]の意味では、PBRは必ずしも「エッジルーター」ではありません。たとえば、両方が自律システム境界ルーター（ASBR）である場合があります。別の例として、ＡＲは、ＯＳＰＦエリアボーダールーター（ＡＢＲ）であるＰＢＲに接続された「アクセスルーター」であり得る。他の多くの展開シナリオが可能です。ただし、PBRは常に「バックボーン」または「コア」ネットワークの境界を定めていると見なされます。 ARからのマルチキャストデータストリームは、コアネットワークを介して入力PBRから1つ以上の出力PBRにトンネリングされます。 PBRが接続されているARから学習したマルチキャストルーティング情報は、PBRのグローバルテーブルに格納されます。 PBRはBGPを使用して、マルチキャストルーティングと自動検出情報を相互に配信します。これは、[RFC6513]、[RFC6514]、およびこのドキュメントで変更されたその他のMVPN仕様の手順に従って行われます。
In general, PBRs follow the same BGP-MVPN procedures that PE routers follow, except that these procedures are adapted to be applicable to the global table rather than to a VRF. Details are provided in subsequent sections of this document.
一般に、PBRはPEルータが実行するのと同じBGP-MVPN手順に従いますが、これらの手順はVRFではなくグローバルテーブルに適用できるようになっています。詳細は、このドキュメントの後続のセクションで説明されています。
By supporting GTM using the BGP procedures designed for MVPN, one obtains a single control plane that governs the use of both VPN and non-VPN multicast. Most of the features and characteristics of MVPN carry over automatically to GTM. These include scaling, aggregation, flexible choice of tunnel technology in the SP network, support for both segmented and non-segmented tunnels, ability to use wildcards to identify sets of multicast flows, support for the Any-Source Multicast (ASM), Source-Specific Multicast (SSM), and Bidirectional (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast flows over either an IPv4 or IPv6 SP infrastructure, support for unsolicited flooded data (including support for Bootstrap Router (BSR) as an RP-to-group mapping protocol), etc.
MVPN用に設計されたBGP手順を使用してGTMをサポートすることにより、VPNマルチキャストと非VPNマルチキャストの両方の使用を制御する単一のコントロールプレーンを取得できます。 MVPNのほとんどの機能と特性は、自動的にGTMに引き継がれます。これらには、スケーリング、集約、SPネットワークでのトンネル技術の柔軟な選択、セグメント化されたトンネルと非セグメント化されたトンネルの両方のサポート、マルチキャストフローのセットを識別するためのワイルドカードの使用機能、Any-Source Multicast（ASM）のサポート、Source-特定のマルチキャスト（SSM）、および双方向（双方向）マルチキャストパラダイム、IPv4またはIPv6 SPインフラストラクチャ上のIPv4とIPv6の両方のマルチキャストフローのサポート、非送信請求フラッディングデータのサポート（ブートストラップルーター（BSR）のサポートを含む） -グループマッピングプロトコル）など
This document not only uses MVPN procedures for GTM but also, insofar as possible, uses the same protocol elements, encodings, and formats. The BGP Updates for GTM thus use the same Subsequent Address Family Identifier (SAFI) and have the same Network Layer Reachability Information (NLRI) format as the BGP Updates for MVPN.
このドキュメントでは、GTMのMVPN手順を使用するだけでなく、可能な限り同じプロトコル要素、エンコーディング、およびフォーマットを使用しています。したがって、GTMのBGPアップデートは、MVPNのBGPアップデートと同じ後続アドレスファミリ識別子（SAFI）を使用し、同じネットワーク層到達可能性情報（NLRI）形式を持っています。
Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over an IPv6 backbone network can be found in [RFC6515]. The procedures and encodings described therein are also applicable to GTM.
IPv6バックボーンネットワーク上でMVPN（IPv4またはIPv6 MVPNトラフィック）をサポートするための詳細は、[RFC6515]にあります。ここで説明されている手順とエンコーディングは、GTMにも適用できます。
[RFC7524] extends [RFC6514] by providing procedures that allow tunnels through the core to be "segmented" at ABRs within the core. The ABR segmentation procedures are also applicable to GTM as defined in the current document. In general, the MVPN procedures of [RFC7524], adapted as specified in the current document, are applicable to GTM.
[RFC7524]は、コアを通るトンネルをコア内のABRで「セグメント化」できるようにする手順を提供することにより、[RFC6514]を拡張します。 ABRセグメンテーション手順は、現在のドキュメントで定義されているGTMにも適用できます。一般に、[RFC7524]のMVPN手順は、現在のドキュメントで指定されているように適合されており、GTMに適用できます。
[RFC7524] also defines a set of procedures for GTM. Those procedures are different from the procedures defined in the current document, and the two sets of procedures are not interoperable with each other. The two sets of procedures can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same multicast group addresses. See Section 3 for more details.
[RFC7524]は、GTMの一連の手順も定義しています。これらの手順は、現在のドキュメントで定義されている手順とは異なり、2つの手順のセットは相互運用できません。 2つの手順のセットは、同じマルチキャストフローまたは同じマルチキャストグループアドレスに適用されない限り、同じネットワーク内で共存できます。詳細については、セクション3を参照してください。
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]で説明されているように解釈されます。
In general, PBRs support Global Table Multicast by using the procedures that PE routers use to support VPN multicast. For GTM, where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one should interpret that to mean the interface between the AR and the PBR. For GTM, where [RFC6513] and [RFC6514] talk about the "backbone" network, one should interpret that to mean the part of the network that is delimited by the PBRs.
一般に、PBRは、PEルータがVPNマルチキャストをサポートするために使用する手順を使用して、グローバルテーブルマルチキャストをサポートします。 GTMの場合、[RFC6513]と[RFC6514]が「PE-CEインターフェース」について語る場合、ARとPBR間のインターフェースを意味すると解釈する必要があります。 GTMの場合、[RFC6513]と[RFC6514]が「バックボーン」ネットワークについて話している場合、PBRによって区切られているネットワークの一部を意味すると解釈する必要があります。
A few adaptations to the procedures of [RFC6513] and [RFC6514] need to be made. Those adaptations are described in the following sub-sections.
[RFC6513]と[RFC6514]の手順にいくつかの変更を加える必要があります。これらの適応については、次のサブセクションで説明します。
The MVPN procedures require the use of BGP routes, defined in [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to these simply as "MCAST-VPN routes". [RFC6514] defines the Network Layer Reachability Information (NLRI) format for MCAST-VPN routes.
MVPNの手順では、SAFI値が5の[RFC6514]で定義されているBGPルート（「MCAST-VPN」）を使用する必要があります。これらを単に「MCAST-VPNルート」と呼びます。 [RFC6514]は、MCAST-VPNルートのネットワーク層到達可能性情報（NLRI）形式を定義します。
The NLRI field always begins with a "Route Type" octet, and, depending on the route type, may be followed by a Route Distinguisher (RD) field.
NLRIフィールドは常に「Route Type」オクテットで始まり、ルートタイプによっては、Route Distinguisher（RD）フィールドが続く場合があります。
When a PBR originates an MCAST-VPN route in support of GTM, the RD field (for those routes types where it is defined) of that route's NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF may have an RD of zero, this allows MCAST-VPN routes that are about GTM to be distinguished from MCAST-VPN routes that are about VPNs.
PBRがGTMをサポートするMCAST-VPNルートを発信する場合、そのルートのNLRIのRDフィールド（定義されているルートタイプの場合）をゼロ（つまり、64ビットのゼロ）に設定する必要があります。 RDがゼロのVRFはない可能性があるため、GTMに関するMCAST-VPNルートを、VPNに関するMCAST-VPNルートと区別することができます。
The MVPN procedures require all MCAST-VPN routes to carry Route Targets (RTs). When a PE router receives an MCAST-VPN route, it processes the route in the context of a particular VRF if and only if the route is carrying an RT that is configured as one of that VRF's "import RTs".
MVPN手順では、ルートターゲット（RT）を伝送するためにすべてのMCAST-VPNルートが必要です。 PEルータがMCAST-VPNルートを受信すると、そのルートがそのVRFの「インポートRT」の1つとして設定されているRTを伝送している場合に限り、特定のVRFのコンテキストでルートを処理します。
There are two different kinds of RT used in MVPN.
MVPNで使用されるRTには2つの異なる種類があります。
o One kind of RT is carried only by the following MCAST-VPN route types: C-multicast Shared Tree Joins, C-multicast Source Tree Joins, and Leaf auto-discovery routes (A-D routes). This kind of RT identifies the PE router that has been selected by the route's originator as the "Upstream PE" or as the "Upstream Multicast Hop" (UMH) for a particular (set of) multicast flow(s). Per [RFC6514] and [RFC6515], this RT must be an IPv4-address-specific or IPv6- address-specific Extended Community (EC), whose Global Administrator field identifies the Upstream PE or the UMH. If the Global Administrator field identifies the Upstream PE, the Local Administrator field identifies a particular VRF in that PE.
o 1種類のRTは、次のMCAST-VPNルートタイプによってのみ伝送されます。Cマルチキャスト共有ツリー結合、Cマルチキャストソースツリー結合、およびリーフ自動検出ルート（A-Dルート）。この種類のRTは、ルートの発信元によって選択されたPEルーターを、特定の（セットの）マルチキャストフローの「アップストリームPE」または「アップストリームマルチキャストホップ」（UMH）として識別します。 [RFC6514]および[RFC6515]に従って、このRTはIPv4アドレス固有またはIPv6-アドレス固有の拡張コミュニティ（EC）である必要があり、そのグローバル管理者フィールドはアップストリームPEまたはUMHを識別します。 Global AdministratorフィールドがアップストリームPEを識別する場合、Local AdministratorフィールドはそのPEの特定のVRFを識別します。
The GTM procedures of this document require the use of this type of RT, in exactly the same situations where it is used in the MVPN specification [RFC6514]. However, one adaptation is necessary: the Local Administrator field of this kind of RT MUST always be set to zero, thus implicitly identifying the global table rather than identifying a VRF. We will refer to this kind of RT as an "upstream-node-identifying RT".
このドキュメントのGTM手順では、MVPN仕様[RFC6514]で使用されているのとまったく同じ状況で、このタイプのRTを使用する必要があります。ただし、1つの適応が必要です。この種類のRTのローカル管理者フィールドは常にゼロに設定する必要があるため、VRFを識別するのではなく、暗黙的にグローバルテーブルを識別します。この種のRTを「上流ノード識別RT」と呼びます。
o The other kind of RT is the conventional RT first specified in [RFC4364]. It does not necessarily identify a particular router by address but is used to constrain the distribution of VPN routes and to ensure that a given VPN route is processed in the context of a given VRF if and only if the route is carrying an RT that has been configured as one of that VRF's "import RTs".
o 他の種類のRTは、[RFC4364]で最初に指定された従来のRTです。これは必ずしも特定のルーターをアドレスで識別する必要はありませんが、VPNルートの配布を制約し、特定のVPNルートが特定のVRFのコンテキストで確実に処理されるようにするために使用されます。そのVRFの「インポートRT」の1つとして構成されます。
Whereas every VRF must be configured with at least one import RT, there has been no requirement to configure any RTs for the global table of any router until now. As stated above, this document makes the use of upstream-node-identifying RTs mandatory for GTM. This document makes the use of non-upstream-node-identifying RTs OPTIONAL for GTM.
すべてのVRFには少なくとも1つのインポートRTを設定する必要がありますが、これまでは、ルータのグローバルテーブルにRTを設定する必要はありませんでした。上記のように、このドキュメントでは、GTMに必須の上流ノード識別RTを使用しています。このドキュメントでは、GTMのオプションとして、上流ノードを特定しないRTを使用しています。
The procedures for the use of RTs in GTM are the following:
GTMでRTを使用する手順は次のとおりです。
o If the global table of a particular PBR is NOT configured with any import RTs, then a received MCAST-VPN route is processed in the context of the global table only if it is carrying no RTs or if it is carrying an upstream-node-identifying RT whose Global Administrator field identifies that PBR.
o 特定のPBRのグローバルテーブルがインポートRTで構成されていない場合、受信したMCAST-VPNルートは、RTを運んでいない場合、またはアップストリームノードを識別している場合にのみ、グローバルテーブルのコンテキストで処理されます。グローバル管理者フィールドがそのPBRを識別するRT。
o The global table in each PBR MAY be configured with (a) a set of export RTs to be attached to MCAST-VPN routes that are originated to support GTM and (b) a set of import RTs for GTM.
o 各PBRのグローバルテーブルは、（a）GTMをサポートするために作成されたMCAST-VPNルートにアタッチされるエクスポートRTのセット、および（b）GTMのインポートRTのセットで構成できます。
If the global table of a given PBR has been so configured, the PBR will process a received MCAST-VPN route in the context of the global table if and only if the route carries an RT that is one of the global table's import RTs or if the route carries an upstream-node-identifying RT whose Global Administrator field identifies the PBR.
特定のPBRのグローバルテーブルがそのように構成されている場合、PBRは、ルートがグローバルテーブルのインポートRTの1つであるRTを運ぶ場合、またはルートが次の場合にのみ、グローバルテーブルのコンテキストで受信したMCAST-VPNルートを処理します。ルートには、グローバル管理者フィールドがPBRを識別する上流ノードを識別するRTが含まれます。
If the global tables are configured with RTs, care must be taken to ensure that the RTs configured for the global table are distinct from any RTs used in support of MVPN (except in the case where it is actually intended to create an "extranet" [MVPN-extranet] in which some sources are reachable in global table context while others are reachable in VPN context.)
グローバルテーブルがRTで構成されている場合、グローバルテーブル用に構成されたRTがMVPNのサポートで使用されるRTと異なるように注意する必要があります（実際に「エクストラネット」を作成することを意図している場合を除きます）[ MVPN-extranet]では、一部のソースはグローバルテーブルコンテキストで到達可能であり、他のソースはVPNコンテキストで到達可能です）。
The "RT Constraint" procedures of [RFC4684] MAY be used to constrain the distribution of MCAST-VPN routes (or other routes) that carry RTs that have been configured as import RTs for GTM. (This includes the upstream-node-identifying RTs.)
[RFC4684]の「RT制約」手順を使用して、GTMのインポートRTとして構成されているRTを伝送するMCAST-VPNルート（または他のルート）の配布を制約できます。 （これには、上流ノードを識別するRTが含まれます。）
N.B.: If the "RT Constraint" procedures of [RFC4684] are deployed, but the MCAST-VPN routes are not carrying RTs, then proper operation requires the "default behavior" specified for the MCAST-VPN address family in Section 3 ("Default Behavior") of [RTC_without_RTs].
注：[RFC4684]の「RT制約」手順が導入されているが、MCAST-VPNルートがRTを伝送していない場合、適切な操作には、セクション3のMCAST-VPNアドレスファミリに指定された「デフォルトの動作」が必要です（「デフォルト[RTC_without_RTs]の動作 "）。
In [RFC6513], the UMH-eligible routes (see Section 5.1.1 of [RFC6513], "Eligible Routes for UMH Selection") are generally routes of SAFI 128 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes) and are required to carry RTs. These RTs determine which VRFs import which such routes. However, for GTM, when the UMH-eligible routes may be routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. This document does NOT specify any new rules for determining whether a SAFI 1, 2, or 4 route is to be imported into the global table of any PBR.
[RFC6513]では、UMH適格ルート（[RFC6513]のセクション5.1.1、「UMH選択の適格ルート」を参照）は通常、SAFI 128（ラベル付きVPN-IPルート）または129（VPN-IPマルチキャストルート）のルートです。 ）およびRTを運ぶために必要です。これらのRTは、どのVRFがどのようなルートをインポートするかを決定します。ただし、GTMの場合、UMH適格ルートがSAFI 1、2、または4のルートである可能性がある場合、RTを伝送するためにルートは必要ありません。このドキュメントでは、SAFI 1、2、または4のルートをPBRのグローバルテーブルにインポートするかどうかを決定するための新しいルールを指定していません。
Section 5.1 of [RFC6513] defines procedures by which a PE router determines the "C-root", the "Upstream Multicast Hop" (UMH), the "Upstream PE", and the "Upstream RD" of a given multicast flow. (In non-VPN multicast documents, the UMH of a multicast flow at a particular router is generally known as the "RPF neighbor" for that flow.) It also defines procedures for determining the "Source AS" of a particular flow. Note that in GTM, the "Upstream PE" is actually the "Upstream PBR".
[RFC6513]のセクション5.1は、PEルーターが特定のマルチキャストフローの「Cルート」、「アップストリームマルチキャストホップ」（UMH）、「アップストリームPE」、および「アップストリームRD」を決定する手順を定義しています。 （非VPNマルチキャストドキュメントでは、特定のルーターでのマルチキャストフローのUMHは一般に、そのフローの「RPFネイバー」と呼ばれます。）また、特定のフローの「送信元AS」を決定する手順も定義します。 GTMでは、「アップストリームPE」は実際には「アップストリームPBR」であることに注意してください。
The definition of the C-root of a flow is the same for GTM as for MVPN.
フローのCルートの定義は、GTMの場合とMVPNの場合と同じです。
For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source AS of a flow, one looks up the C-root of the flow in a particular VRF and finds the "UMH-eligible" routes (see Section 5.1.1 of [RFC6513]) that "match" the C-root. From among these, one is chosen as the "Selected UMH Route".
MVPNの場合、フローのUMH、アップストリームPE、アップストリームRD、およびソースASを決定するには、特定のVRFでフローのCルートを検索し、「UMH適格」ルートを見つけます（セクション5.1.1を参照）。 [RFC6513]の）Cルートと「一致」します。これらの中から、1つが「選定UMHルート」として選定されます。
For GTM, the C-root is, of course, looked up in the global table, rather than in a VRF. For MVPN, the UMH-eligible routes are routes of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of UMH determination, if a SAFI 1 route and a SAFI 4 route contain the same IP prefix in their respective NLRI fields, then the two routes are considered by the BGP best-path selection process to be comparable.
GTMの場合、Cルートはもちろん、VRFではなくグローバルテーブルで検索されます。 MVPNの場合、UMH適格ルートはSAFI 128または129のルートです。GTMの場合、UMH適格ルートはSAFI 1、SAFI 4、またはSAFI 2のルートです。グローバルテーブルにSAFI 2のルートがインポートされている場合、これらはUMHに適格なルートです。それ以外の場合、SAFI 1またはSAFI 4のルートは、UMH適格ルートです。 UMHの決定のために、SAFI 1ルートとSAFI 4ルートのそれぞれのNLRIフィールドに同じIPプレフィックスが含まれている場合、2つのルートはBGPベストパス選択プロセスで比較可能と見なされます。
[RFC6513] defines procedures for determining which of the UMH-eligible routes that match a particular C-root is to become the Selected UMH Route. With one exception, these procedures are also applicable to GTM. The one exception is the following. Section 9.1.2 of [RFC6513] defines a particular method of choosing the Upstream PE, known as "Single Forwarder Selection" (SFS). This procedure MUST NOT be used for GTM (see Section 2.3.4 for an explanation of why the SFS procedure cannot be applied to GTM).
[RFC6513]は、特定のCルートに一致するUMH適格ルートのどれが選択されたUMHルートになるかを決定するための手順を定義しています。 1つの例外を除いて、これらの手順はGTMにも適用できます。 1つの例外は次のとおりです。 [RFC6513]のセクション9.1.2は、「シングルフォワーダー選択」（SFS）と呼ばれる、アップストリームPEを選択する特定の方法を定義しています。この手順をGTMに使用してはなりません（SFS手順をGTMに適用できない理由の説明については、セクション2.3.4を参照してください）。
In GTM, the "Upstream RD" of a multicast flow is always considered to be zero and is NOT determined from the Selected UMH Route.
GTMでは、マルチキャストフローの「アップストリームRD」は常にゼロと見なされ、選択されたUMHルートから決定されません。
The MVPN specifications require that when BGP is used for distributing multicast routing information, the UMH-eligible routes MUST carry the VRF Route Import EC and the Source AS EC. To determine the Upstream PE and Source AS for a particular multicast flow, the Upstream PE and Source AS are determined, respectively, from the VRF Route Import EC and the Source AS EC of the Selected UMH Route for that flow. These ECs are generally attached to the UMH-eligible routes by the PEs that originate the routes.
MVPN仕様では、マルチキャストルーティング情報の配信にBGPが使用される場合、UMH適格ルートはVRFルートインポートECおよびソースAS ECを伝送する必要があります。特定のマルチキャストフローのアップストリームPEおよびソースASを決定するには、そのフローの選択されたUMHルートのVRFルートインポートECおよびソースAS ECから、アップストリームPEおよびソースASをそれぞれ決定します。これらのECは通常、ルートを発信するPEによってUMH適格ルートに接続されます。
In GTM, there are certain situations in which it is allowable to omit the VRF Route Import EC and/or the Source AS EC from the UMH-eligible routes. The following sub-sections specify the various options for determining the Upstream PBR and the Source AS in GTM.
GTMでは、UMH適格ルートからVRFルートインポートECおよび/またはソースAS ECを省略できる特定の状況があります。次のサブセクションでは、GTMでアップストリームPBRとソースASを決定するためのさまざまなオプションを指定します。
The procedures in Section 2.3.1 MUST be implemented. The procedures in Sections 2.3.2 and 2.3.3 are OPTIONAL to implement. It should be noted that while the optional procedures may be useful in particular deployment scenarios, there is always the potential for interoperability problems when relying on OPTIONAL procedures.
セクション2.3.1の手順を実装する必要があります。セクション2.3.2および2.3.3の手順は、実装するオプションです。オプションの手順は特定の展開シナリオで役立つ場合がありますが、オプションの手順に依存すると、相互運用性の問題が常に発生する可能性があることに注意してください。
If the UMH-eligible routes have a SAFI of 1, 2, or 4, then they MAY carry the VRF Route Import EC and/or the Source AS EC. If the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the VRF Route Import EC, then the Upstream PBR is determined from that EC. Similarly, if the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the Source AS EC, the Source AS is determined from that EC.
UMH適格ルートのSAFIが1、2、または4の場合、それらはVRFルートインポートECおよび/またはソースAS ECを運ぶことができます（MAY）。選択したUMHルートがVRFルートインポートECを伝送するSAFI 1、2、または4のルートである場合、アップストリームPBRはそのECから決定されます。同様に、選択されたUMHルートがソースAS ECを伝送するSAFI 1、2、または4のルートである場合、ソースASはそのECから決定されます。
When the procedure of this section is used, a PBR that distributes a UMH-eligible route to other PBRs is responsible for ensuring that the VRF Route Import and Source AS ECs are attached to it.
このセクションの手順を使用する場合、UMH適格ルートを他のPBRに配布するPBRは、VRFルートインポートとソースAS ECがそれに接続されていることを確認する責任があります。
If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a VRF Route Import EC, then the Upstream PBR is determined as specified in Sections 2.3.2 or 2.3.3.
選択したUMH適格ルートのSAFIが1、2、または4であるが、VRFルートインポートECを伝送していない場合、セクション2.3.2または2.3.3で指定されているように、アップストリームPBRが決定されます。
If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a Source AS EC, then the Source AS is considered to be the local AS.
選択したUMH適格ルートのSAFIが1、2、または4であるが、ソースAS ECを運んでいない場合、ソースASはローカルASと見なされます。
Some service providers may consider it to be undesirable to have the PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or there may be deployment scenarios in which the UMH-eligible routes are not advertised by the PBRs at all. The procedures described in this section provide an alternative that can be used under certain circumstances.
一部のサービスプロバイダーは、PBRがVRFルートインポートECをすべてのUMH適格ルートに配置することは望ましくないと考える場合があります。または、UMH対応のルートがPBRによってまったくアドバタイズされない展開シナリオが存在する可能性があります。このセクションで説明する手順は、特定の状況で使用できる代替手段を提供します。
The procedures in this section are OPTIONAL.
このセクションの手順はオプションです。
In this alternative procedure, each PBR MUST originate a BGP route of SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself. This route MUST carry a VRF Route Import EC that identifies the PBR. The address that appears in the Global Administrator field of that EC MUST be the same address that appears in the NLRI and in the Next Hop field of that route. This route MUST also carry a Source AS EC identifying the AS of the PBR.
この代替手順では、各PBRは、NLRIがPBR自体のIPアドレスであるSAFI 1、2、または4のBGPルートを作成する必要があります。このルートは、PBRを識別するVRFルートインポートECを伝送する必要があります。そのECのグローバル管理者フィールドに表示されるアドレスは、NLRIおよびそのルートの次ホップフィールドに表示されるアドレスと同じである必要があります。このルートは、PBRのASを識別するソースAS ECも運ぶ必要があります。
Whenever the PBR distributes a UMH-eligible route for which it sets itself as Next Hop, it MUST use this same IP address as the Next Hop of the UMH-eligible route that it used in the route discussed in the prior paragraph.
PBRが自身をネクストホップとして設定するUMH適格ルートを配布する場合は常に、前の段落で説明したルートで使用したUMH適格ルートのネクストホップと同じIPアドレスを使用する必要があります。
When the procedure in this section is used and when a PBR is determining the Selected UMH Route for a given multicast flow, it may find that the Selected UMH Route has no VRF Route Import EC. In this case, the PBR will look up (in the global table) the route to the Next Hop of the Selected UMH Route. If the route to the Next Hop has a VRF Route Import EC, that EC will be used to determine the Upstream PBR, just as if the EC had been attached to the Selected UMH Route.
このセクションの手順が使用され、PBRが特定のマルチキャストフローの選択されたUMHルートを決定している場合、選択されたUMHルートにVRFルートインポートECがないことがわかります。この場合、PBRは（グローバルテーブルで）選択されたUMHルートの次のホップへのルートを検索します。ネクストホップへのルートにVRFルートインポートECがある場合、ECが選択されたUMHルートに接続されているかのように、そのECを使用してアップストリームPBRが決定されます。
If recursive route resolution is required in order to resolve the Next Hop, the Upstream PBR will be determined from the first route with a VRF Route Import EC that is encountered during the recursive route resolution process. (The recursive route resolution process itself is not modified by this document.)
ネクストホップを解決するために再帰ルート解決が必要な場合、アップストリームPBRは、再帰ルート解決プロセス中に発生したVRFルートインポートECを持つ最初のルートから決定されます。 （再帰ルート解決プロセス自体は、このドキュメントでは変更されていません。）
The same procedure can be applied to find the Source AS, except that the Source AS EC is used instead of the VRF Route Import EC.
VRFルートインポートECの代わりにソースAS ECが使用されることを除いて、同じ手順をソースASの検索に適用できます。
Note that this procedure is only applicable in scenarios where it is known that the Next Hop of the UMH-eligible routes is not changed by any router that participates in the distribution of those routes; this procedure MUST NOT be used in any scenario where the Next Hop may be changed between the time one PBR distributes the route and another PBR receives it. The PBRs have no way of determining dynamically whether the procedure is applicable in a particular deployment; this must be made known to the PBRs by provisioning.
この手順は、UMH適格ルートのネクストホップが、これらのルートの配布に参加しているルーターによって変更されないことがわかっているシナリオにのみ適用できることに注意してください。この手順は、1つのPBRがルートを配布してから別のPBRがルートを受信するまでの間にネクストホップが変更される可能性があるシナリオでは使用しないでください。 PBRには、手順が特定の展開に適用可能かどうかを動的に決定する方法がありません。これは、プロビジョニングによってPBRに知らされる必要があります。
Some scenarios in which this procedure can be used are:
この手順を使用できるシナリオは次のとおりです。
o All PBRs are in the same AS.
o すべてのPBRは同じASにあります。
o The UMH-eligible routes are distributed among the PBRs by a Route Reflector (that does not change the Next Hop).
o UMH適格ルートは、ルートリフレクター（次ホップを変更しない）によってPBR間で配布されます。
o The UMH-eligible routes are distributed from one AS to another through ASBRs that do not change the Next Hop.
o UMH適格ルートは、ネクストホップを変更しないASBRを介して、あるASから別のASに配布されます。
If the procedures of this section are used in scenarios where they are not applicable, GTM will not function correctly.
このセクションの手順が該当しないシナリオで使用された場合、GTMは正しく機能しません。
In particular deployment scenarios, there may be specific procedures that can be used, in those particular scenarios, to determine the Upstream PBR for a given multicast flow.
特定の展開シナリオでは、特定のシナリオで、特定のマルチキャストフローのアップストリームPBRを決定するために使用できる特定の手順がある場合があります。
Suppose the PBRs neither put the VRF Route Import EC on the UMH-eligible routes, nor distribute BGP routes with their own addresses in the NLRI. It may still be possible, by using specific knowledge about the deployment, to determine the Upstream PBR for a given multicast flow.
PBRがVRFルートインポートECをUMH適格ルートに配置せず、NLRIで独自のアドレスを使用してBGPルートを配布しないとします。展開に関する特定の知識を使用することで、特定のマルチキャストフローのアップストリームPBRを決定することがまだ可能である場合があります。
For example, suppose it is known that all the PBRs are in the same OSPF area. It may be possible to determine the Upstream PBR for a given multicast flow by looking at the link state database to see which router is attached to the flow's C-root.
たとえば、すべてのPBRが同じOSPFエリアにあることがわかっているとします。リンク状態データベースを調べて、フローのCルートに接続されているルーターを確認することにより、特定のマルチキャストフローのアップストリームPBRを特定できる場合があります。
As another example, suppose it is known that the set of PBRs is fully meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in its global table, the C-root of a particular multicast flow, it may find that the next-hop interface is a particular TE tunnel. If it can determine the identity of the router at the other end of that TE tunnel, it can deduce that the router is the Upstream PBR for that flow.
別の例として、PBRのセットがトラフィックエンジニアリング（TE）トンネルを介して完全にメッシュ化されていることがわかっているとします。 PBRがグローバルテーブルで特定のマルチキャストフローのCルートを検索すると、ネクストホップインターフェイスが特定のTEトンネルであることがわかります。そのTEトンネルの反対側にあるルータのIDを判別できる場合、ルータがそのフローのアップストリームPBRであると推定できます。
This is not an exhaustive set of examples. Any procedure that correctly determines the Upstream PBR in a given deployment scenario MAY be used in that scenario.
これは包括的な例ではありません。特定の展開シナリオでアップストリームPBRを正しく決定する手順は、そのシナリオで使用できます。
To see why the SFS procedure cannot be applied to GTM, consider the following example scenario. Suppose some multicast source S is homed to both PBR1 and PBR2, and suppose that both PBRs export a route (of SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. These two routes will be considered comparable by the BGP decision process. A route reflector receiving both routes may thus choose to redistribute just one of the routes to S, the one chosen by the best-path algorithm. Different route reflectors may even choose different routes to redistribute (i.e., one route reflector may choose the route to S via PBR1 as the best path, while another chooses the route to S via PBR2 as the best path). As a result, some PBRs may receive only the route to S via PBR1, and some may receive only the route to S via PBR2. In that case, it is impossible to ensure that all PBRs will choose the same route to S.
SFS手順をGTMに適用できない理由を確認するには、次のシナリオ例を検討してください。一部のマルチキャストソースSがPBR1とPBR2の両方をホームとし、両方のPBRがNLRIがSのアドレスと一致するプレフィックスである（SAFI 1、2、または4の）ルートをエクスポートするとします。これら2つのルートは、 BGP決定プロセス。したがって、両方のルートを受信するルートリフレクタは、ルートの1つだけをSに再配布することを選択できます。これは、ベストパスアルゴリズムによって選択されたものです。異なるルートリフレクターは異なるルートを選択して再配布することもできます（つまり、1つのルートリフレクターはPBR1を介してSへのルートを最適パスとして選択し、別のルートリフレクターはPBR2を介してSへのルートを選択することができます）。その結果、一部のPBRはPBR1を介してSへのルートのみを受信する場合があり、一部はPBR2を介してSへのルートのみを受信する場合があります。その場合、すべてのPBRがSへの同じルートを選択することを保証することは不可能です。
The SFS procedure works in VPN context as long as the following assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, then VRF-x and VRF-y have been configured with different RDs. In VPN context, the route to S is of SAFI 128 or 129 and thus has an RD in its NLRI. So the route to S via PE1 will not have the same NLRI as the route to S via PE2. As a result, all PEs will see both routes, and the PEs can implement a procedure that ensures that they all pick the same route to S.
SFS手順は、次の仮定が当てはまる限り、VPNコンテキストで機能します。SがPE1のVRF-xとPE2のVRF-yにホームしている場合、VRF-xとVRF-yは異なるRDで構成されています。 VPNコンテキストでは、SへのルートはSAFI 128または129であるため、NLRIにRDがあります。したがって、PE1を介したSへのルートには、PE2を介したSへのルートと同じNLRIはありません。その結果、すべてのPEは両方のルートを認識し、PEはすべてがSへの同じルートを確実に選択する手順を実装できます。
That is, the SFS procedure of [RFC6513] relies on the UMH-eligible routes being of SAFI 128 or 129 and relies on certain VRFs being configured with distinct RDs. Thus, the procedure cannot be applied to GTM.
つまり、[RFC6513]のSFS手順は、SAMH 128または129のUMH適格ルートに依存し、特定のRDで構成されている特定のVRFに依存します。したがって、この手順はGTMには適用できません。
One might think that the SFS procedure could be applied to GTM as long as the procedures defined in [ADD-PATH] are applied to the UMH-eligible routes. Using the [ADD-PATH] procedures, the BGP speakers could advertise more than one path to a given prefix. Typically, [ADD-PATH] is used to report the n best paths, for some small value of n. However, this is not sufficient to support SFS, as can be seen by examining the following scenario:
[ADD-PATH]で定義された手順がUMH適格ルートに適用される限り、SFS手順をGTMに適用できると考える人もいるかもしれません。 [ADD-PATH]手順を使用して、BGPスピーカーは、特定のプレフィックスに複数のパスをアドバタイズできます。通常、[ADD-PATH]は、nの小さな値に対して、n個の最適パスを報告するために使用されます。ただし、次のシナリオを調べるとわかるように、これはSFSをサポートするには十分ではありません。
AS-X | AS-Y | AS-Z
| |
S--PBR1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | |
| / \ | |
|--PBR2---ASBR3--|--ASBR4--|---ASBR6
| |
In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to S. Similarly, PBR2 reports to both ASBR1 and ASBR3 that it has a route to S. Using the procedures in [ADD-PATH], ASBR1 reports both routes to ASBR2, and ASBR3 reports both routes to ASBR4. Now AS-Y sees 4 paths to S. The AS-Z ASBRs will each see eight paths (four via ASBR2 and four via ASBR4). To avoid this explosion in the number of paths, a BGP speaker that uses [ADD-PATH] is usually considered to report only the n best paths. However, there is then no guarantee that the reported set of paths will contain at least one path via PBR1 and at least one path via PBR2. Without such a guarantee, the SFS procedure will not work.
AS-Xでは、PBR1はASBR1とASBR3の両方にSへのルートがあることを報告します。同様に、PBR2はASBR1とASBR3の両方にSへのルートがあることを報告します。[ADD-PATH]の手順を使用して、ASBR1は両方に報告しますASBR2へのルート、およびASBR3はASBR4への両方のルートを報告します。これでAS-YはSへの4つのパスを認識します。AS-ZASBRはそれぞれ8つのパスを認識します（4つはASBR2経由、4つはASBR4経由）。パス数のこの爆発を回避するために、[ADD-PATH]を使用するBGPスピーカーは通常、n個の最適パスのみを報告すると見なされます。ただし、報告されたパスのセットにPBR1を介した少なくとも1つのパスとPBR2を介した少なくとも1つのパスが含まれるという保証はありません。そのような保証がないと、SFS手順は機能しません。
The MVPN specifications allow multicast flows to be carried on either Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an Inclusive Tunnel of a particular VPN, it is sent to all PEs in that VPN. When sent on a Selective Tunnel of a particular VPN, it may be sent to only a subset of the PEs in that VPN.
MVPN仕様では、マルチキャストフローを包含トンネルまたは選択トンネルのいずれかで伝送できます。フローが特定のVPNの包含トンネルで送信されると、そのVPN内のすべてのPEに送信されます。特定のVPNの選択トンネルで送信される場合、そのVPN内のPEのサブセットのみに送信される場合があります。
This document allows the use of either Inclusive Tunnels or Selective Tunnels for GTM. However, any service provider electing to use Inclusive Tunnels for GTM should carefully consider whether sending a multicast flow to ALL its PBRs would result in problems of scale. There are potentially many more PBRs for GTM than PEs for a particular VPN. If the set of PBRs is large and growing, but most multicast flows do not need to go to all the PBRs, the exclusive use of Selective Tunnels may be a better option.
このドキュメントでは、GTMにインクルーシブトンネルまたは選択的トンネルのいずれかを使用できます。ただし、GTMにインクルーシブトンネルを使用することを選択するサービスプロバイダーは、すべてのPBRにマルチキャストフローを送信すると、スケールの問題が発生するかどうかを慎重に検討する必要があります。 GTMのPBRは、特定のVPNのPEよりも潜在的に多くあります。 PBRのセットが大きく成長しているが、ほとんどのマルチキャストフローがすべてのPBRに行く必要がない場合は、選択的トンネルを排他的に使用することをお勧めします。
Per [RFC6514], there are certain conditions under which it is NOT required for a PE router implementing MVPN to originate one or more Intra-AS Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes. These conditions also apply to PBRs implementing GTM.
[RFC6514]によると、MVPNを実装するPEルーターが1つ以上のIntra-ASインクルーシブプロバイダーマルチキャストサービスインターフェイス（I-PMSI）A-Dルートを発信する必要がない特定の条件があります。これらの条件は、GTMを実装するPBRにも適用されます。
In addition, a PBR implementing GTM is NOT required to originate an Intra-AS I-PMSI A-D route if both of the following conditions hold:
さらに、次の両方の条件が満たされている場合、GTMを実装するPBRは、Intra-AS I-PMSI A-Dルートを開始する必要はありません。
o The PBR is not using Inclusive Tunnels for GTM, and
o PBRがGTMにインクルーシブトンネルを使用していない。
o The distribution of the C-multicast Shared Tree Join and C-multicast Source Tree Join routes is done in such a manner that the Next Hop of those routes does not change.
o Cマルチキャスト共有ツリー参加ルートとCマルチキャストソースツリー参加ルートの配布は、これらのルートのネクストホップが変更されないように行われます。
Please see also the sections on RD and RT usage (Sections 2.1 and 2.2, respectively).
RDおよびRTの使用に関するセクション（それぞれセクション2.1および2.2）も参照してください。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
RDとRTの使用に関するセクション（セクション2.1および2.2）で指定されているものを除き、これらのルートの開始、配布、および処理に関するGTM固有の手順はありません。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
RDとRTの使用に関するセクション（セクション2.1および2.2）で指定されているものを除き、これらのルートの開始、配布、および処理に関するGTM固有の手順はありません。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
RDとRTの使用に関するセクション（セクション2.1および2.2）で指定されているものを除き、これらのルートの開始、配布、および処理に関するGTM固有の手順はありません。
Please see the sections on RD and RT usage (Sections 2.1 and 2.2) for information that applies to the origination and distribution of Source Active A-D routes. Additional procedures governing the use of Source Active A-D routes are given in the sub-sections of this section.
ソースアクティブA-Dルートの発生と配信に適用される情報については、RDおよびRTの使用に関するセクション（セクション2.1および2.2）を参照してください。ソースアクティブA-Dルートの使用を管理する追加の手順は、このセクションのサブセクションに記載されています。
To carry out the procedures specified in [RFC6514] (e.g., in Section 13.2 of that document), it is sometimes necessary for an egress PE to determine the ingress PE that originated a given Source Active A-D route. The procedure used in [RFC6514] to find the originator of a Source Active A-D route assumes that no two routes have the same RD unless they have been originated by the same PE. However, this assumption is not valid in GTM, because each Source Active A-D route used for GTM will have an RD of 0, and all the UMH-eligible routes also have an RD of 0. So GTM requires a different procedure for determining the originator of a Source Active A-D route.
[RFC6514]で指定された手順（たとえば、そのドキュメントのセクション13.2）を実行するには、出力PEが特定のソースアクティブA-Dルートを発信した入力PEを特定する必要がある場合があります。 [RFC6514]でSource Active A-Dルートの発信者を見つけるために使用される手順は、同じPEによって発信されたのでない限り、2つのルートが同じRDを持たないことを前提としています。ただし、GTMで使用される各ソースアクティブADルートのRDは0であり、すべてのUMH適格ルートのRDも0であるため、この仮定はGTMでは無効です。したがって、GTMは発信者を決定するために異なる手順を必要としますソースアクティブADルートの。
In GTM, the procedure for determining the originating PE of a Source Active A-D route is the following:
GTMでは、ソースアクティブA-Dルートの発信PEを決定する手順は次のとおりです。
o When a Source Active A-D route is originated, the originating PE MAY attach a VRF Route Import Extended Community to the route.
o ソースアクティブA-Dルートが発信されると、発信PEはVRFルートインポート拡張コミュニティをルートにアタッチできます（MAY）。
o When a Source Active A-D route is distributed by one BGP speaker to another, then:
o ソースアクティブA-Dルートが1つのBGPスピーカーから別のスピーカーに配信されると、次のようになります。
* If the Source Active A-D route does not carry the VRF Route Import EC, the BGP speaker distributing the route MUST NOT change the route's Next Hop field.
* ソースアクティブA-DルートがVRFルートインポートECを伝送しない場合、ルートを配布するBGPスピーカーはルートの次ホップフィールドを変更してはなりません（MUST NOT）。
* If the Source Active A-D route does carry the VRF Route Import EC, the BGP speaker distributing the route MAY change the route's Next Hop field to itself.
* ソースアクティブA-DルートがVRFルートインポートECを伝送する場合、ルートを配布するBGPスピーカーはルートのNext Hopフィールドをそれ自体に変更できます（MAY）。
o When an egress PE needs to determine the originator of a Source Active A-D route, then:
o 出力PEがソースアクティブA-Dルートの発信元を決定する必要がある場合、次のようになります。
* If the Source Active A-D route carries the VRF Route Import EC, the originating PE is the PE identified in the Global Administrator field of that EC.
* ソースアクティブA-DルートがVRFルートインポートECを伝送する場合、元のPEはそのECのグローバルアドミニストレーターフィールドで識別されるPEです。
* If the Source Active A-D route does not carry the VRF Route Import EC, the originating PE is the PE identified in the route's Next Hop field.
* ソースアクティブA-DルートがVRFルートインポートECを伝送しない場合、発信PEはルートのNext Hopフィールドで識別されるPEです。
If some site has receivers for a particular ASM group G, then it is possible (by the procedures of [RFC6514]) that every PBR attached to a site with a source for group G will originate a Source Active A-D route whose NLRI identifies that source and group. These Source Active A-D routes may be distributed to every PBR. If only a relatively small number of PBRs are actually interested in traffic from group G, but there are many sources for group G, this could result in a large number of (S,G) Source Active A-D routes being installed in a large number of PBRs that have no need of them.
一部のサイトに特定のASMグループGのレシーバーがある場合、（[RFC6514]の手順により）グループGのソースを持つサイトに接続されているすべてのPBRが、NLRIがそのソースを識別するソースアクティブADルートを発信する可能性がありますとグループ。これらのソースアクティブA-Dルートは、すべてのPBRに配布できます。比較的少数のPBRだけが実際にグループGからのトラフィックに関心があるが、グループGのソースが多数ある場合、これにより、多数の（S、G）ソースアクティブADルートが多数インストールされる可能性があります。それらを必要としないPBR。
For GTM, it is possible to constrain the distribution of (S,G) Source Active A-D routes to those PBRs that are interested in GTM traffic to group G. This can be done using the following OPTIONAL procedures:
GTMの場合、グループSへのGTMトラフィックに関心のあるPBRへの（S、G）ソースアクティブA-Dルートの配布を制限できます。これは、次のオプションの手順を使用して実行できます。
o If a PBR originates a C-multicast Shared Tree Join whose NLRI contains (RD=0,*,G), then it dynamically creates an import RT for its global table, where the Global Administrator field of the RT contains the group address G, and the Local Administrator field contains zero. (Note that an IPv6-address-specific RT would need to be used if the group address is an IPv6 address.)
o PBRがNLRIに（RD = 0、*、G）を含むCマルチキャスト共有ツリー結合を発信する場合、PBRはグローバルテーブルのインポートRTを動的に作成します。RTのグローバル管理者フィールドにはグループアドレスGが含まれます。ローカル管理者フィールドにはゼロが含まれています。 （グループアドレスがIPv6アドレスの場合、IPv6アドレス固有のRTを使用する必要があることに注意してください。）
o When a PBR creates such an import RT, it uses "RT Constraint" procedures [RFC4684] to advertise its interest in routes that carry this RT.
o PBRがそのようなインポートRTを作成するとき、PRTは「RT制約」手順[RFC4684]を使用して、このRTを伝送するルートへの関心を通知します。
o When a PBR originates a Source Active A-D route from its global table, it attaches the RT described above.
o PBRがそのグローバルテーブルからソースアクティブA-Dルートを発信する場合、PBRは上記のRTをアタッチします。
o When the C-multicast Shared Tree Join is withdrawn, so is the corresponding RT constrain route, and the corresponding RT is removed as an import RT of its global table.
o Cマルチキャスト共有ツリー結合が撤回されると、対応するRT制約ルートも撤回され、対応するRTはそのグローバルテーブルのインポートRTとして削除されます。
These procedures enable a PBR to automatically filter all Source Active A-D routes that are about multicast groups in which the PBR has no interest.
これらの手順により、PBRは、PBRが関係のないマルチキャストグループに関するすべてのソースアクティブA-Dルートを自動的にフィルタリングできます。
This procedure does introduce the overhead of distributing additional "RT Constraint" routes and therefore may not be cost-effective in all scenarios, especially if the number of sources per ASM group is small. This procedure may also result in increased join latency.
この手順では、追加の「RT制約」ルートを配布するオーバーヘッドが発生するため、特にASMグループごとのソースの数が少ない場合は、すべてのシナリオで費用効果が高いとは限りません。この手順では、結合の待機時間が長くなる場合もあります。
Section 11.1.3 of [RFC6514] describes how to determine the IP-address-specific RT(s) that should be attached to a C-multicast route. The "Upstream PE", "Upstream RD", and "Source AS" (as defined in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are first determined. An IP-address-specific RT whose Global Administrator field carries the IP address of the Upstream PE is then attached to the C-multicast route. This procedure also applies to GTM, except that the "Upstream PE" is actually an "Upstream PBR".
[RFC6514]のセクション11.1.3は、Cマルチキャストルートに接続する必要があるIPアドレス固有のRTを決定する方法を説明しています。 CマルチキャストルートのNLRIの「アップストリームPE」、「アップストリームRD」、および「ソースAS」（[RFC6513]のセクション5で定義）が最初に決定されます。次に、グローバル管理者フィールドにアップストリームPEのIPアドレスが含まれるIPアドレス固有のRTがCマルチキャストルートに接続されます。この手順はGTMにも適用されますが、「アップストリームPE」は実際には「アップストリームPBR」です。
Section 11.1.3 of [RFC6514] also specifies that a second IP-address-specific RT be attached to the C-multicast route, if the Source AS of the NLRI of that route is different than the AS of the PE originating the route. The procedure for creating this RT may be summarized as:
[RFC6514]のセクション11.1.3でも、そのルートのNLRIのソースASがルートを発信しているPEのASと異なる場合、2番目のIPアドレス固有のRTがCマルチキャストルートに接続されることを指定しています。このRTを作成する手順は、次のように要約できます。
(a) Determine the Upstream PE, Upstream RD, and Source AS corresponding to the NLRI of the route.
（a）ルートのNLRIに対応するアップストリームPE、アップストリームRD、およびソースASを決定します。
(b) Find the corresponding Inter-AS or Intra-AS I-PMSI A-D route based on (a).
（b）（a）に基づいて、対応するInter-ASまたはIntra-AS I-PMSI A-Dルートを見つけます。
(c) Find the Next Hop of that A-D route.
（c）そのA-Dルートの次のホップを見つけます。
(d) Place the IP address of that Next Hop in the Global Administrator field of the RT.
（d）そのネクストホップのIPアドレスをRTのグローバル管理者フィールドに入力します。
However, for GTM, in scenarios where it is known a priori by a PBR that the Next Hop of the C-multicast Source/Shared Tree Joins does not change during the distribution of those routes, the second RT (the one based on the Next Hop of an I-PMSI A-D route) is not needed and should not be present. In other scenarios, the procedure of Section 11.1.3 of [RFC6514] (as modified by Sections 2.1 and 2.2 of this document) is applied by the PBRs.
ただし、GTMの場合、Cマルチキャストソース/共有ツリー結合のネクストホップがこれらのルートの配布中に変更されないことがPBRによって事前にわかっているシナリオでは、2番目のRT（次のRTに基づくもの） I-PMSI ADルートのホップ）は不要であり、存在すべきではありません。他のシナリオでは、[RFC6514]のセクション11.1.3の手順（このドキュメントのセクション2.1および2.2で変更）がPBRによって適用されます。
[RFC7524] also defines a procedure for GTM that is based on the BGP procedures that were developed for MVPN.
[RFC7524]では、MVPN用に開発されたBGP手順に基づくGTMの手順も定義されています。
However, the GTM procedures of [RFC7524] are different than and are NOT interoperable with the procedures defined in this document.
ただし、[RFC7524]のGTM手順は異なり、このドキュメントで定義されている手順と相互運用できません。
The two sets of procedures can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same ASM multicast group addresses.
2つの手順セットは、同じマルチキャストフローまたは同じASMマルチキャストグループアドレスに適用されない限り、同じネットワーク内で共存できます。
Some of the major differences between the two sets of procedures are the following:
2つの手順のセットの主な違いは次のとおりです。
o The procedures for GTM described in [RFC7524] do not use C-multicast Shared Tree Joins or C-multicast Source Tree Joins at all. The procedures of this document use these C-multicast routes for GTM, setting the RD field of the NLRI to zero.
o [RFC7524]で説明されているGTMの手順では、Cマルチキャスト共有ツリー結合またはCマルチキャストソースツリー結合をまったく使用しません。このドキュメントの手順では、GTMにこれらのCマルチキャストルートを使用し、NLRIのRDフィールドをゼロに設定します。
o The procedures for GTM described in [RFC7524] use Leaf A-D routes instead of C-multicast Shared/Source Tree Join routes. Leaf A-D routes used in that manner can be distinguished from Leaf A-D routes used as specified in [RFC6514] by means of the NLRI format; [RFC7524] defines a new NLRI format for Leaf A-D routes. Whether or not a given Leaf A-D route is being used according to the procedures described in [RFC7524] can be determined from its NLRI. (See Section 6.2.2 ("Leaf A-D Route for Global Table Multicast") of [RFC7524]).
o [RFC7524]で説明されているGTMの手順では、Cマルチキャスト共有/ソースツリー結合ルートの代わりにリーフA-Dルートを使用します。その方法で使用されるリーフA-Dルートは、NLRF形式によって、[RFC6514]で指定されているように使用されるリーフA-Dルートと区別できます。 [RFC7524]は、リーフA-Dルートの新しいNLRI形式を定義します。特定のLeaf A-Dルートが[RFC7524]で説明されている手順に従って使用されているかどうかは、そのNLRIから判断できます。 （[RFC7524]のセクション6.2.2（「グローバルテーブルマルチキャストのリーフA-Dルート」）を参照してください）。
o The Leaf A-D routes used by the current document contain an NLRI that is in the format defined in [RFC6514], NOT in the format as defined in [RFC7524]. The procedures assumed by this document for originating and processing Leaf A-D routes are as specified in [RFC6514], NOT as specified in [RFC7524].
o 現在のドキュメントで使用されているリーフA-Dルートには、[RFC6514]で定義された形式のNLRIが含まれています。[RFC7524]で定義された形式ではありません。リーフA-Dルートの発信と処理のためにこのドキュメントで想定されている手順は、[RFC7524]で指定されているのではなく、[RFC6514]で指定されているとおりです。
o The current document uses an RD value of zero in the NLRI in order to indicate that a particular route is about a Global Table Multicast rather than a VPN multicast. No other semantics are inferred from the fact that RD is zero. [RFC7524] uses two different RD values in its GTM procedures, with semantic differences that depend upon the RD values.
o 現在のドキュメントでは、特定のルートがVPNマルチキャストではなくグローバルテーブルマルチキャストに関するものであることを示すために、NLRIでゼロのRD値を使用しています。 RDがゼロであるという事実から他の意味論は推測されません。 [RFC7524]は、GTMプロシージャで2つの異なるRD値を使用しますが、セマンティックの違いはRD値によって異なります。
o In order for both sets of procedures to co-exist in the same network, the PBRs MUST be provisioned so that for any given IP group address in the global table, all egress PBRs use the same set of procedures for that group address (i.e., for group G, either all egress PBRs use the GTM procedures of this document or all egress PBRs use the GTM procedures of [RFC7524]).
o 両方の手順のセットが同じネットワークで共存するには、PBRをプロビジョニングして、グローバルテーブルの特定のIPグループアドレスに対して、すべての出力PBRがそのグループアドレスに対して同じ手順のセットを使用するようにする必要があります（つまり、グループGの場合、すべての出力PBRがこのドキュメントのGTM手順を使用するか、すべての出力PBRが[RFC7524]のGTM手順を使用します。
The security considerations of this document are primarily the security considerations of the base protocols, as discussed in [RFC6514], [RFC4601], and [RFC5294].
このドキュメントのセキュリティに関する考慮事項は、[RFC6514]、[RFC4601]、および[RFC5294]で説明されているように、主に基本プロトコルのセキュリティに関する考慮事項です。
The protocols and procedures described in this document make use of a type of route (routes with the "MCAST-VPN" BGP SAFI) that was originally designed for use in VPN contexts only. The protocols and procedures described in this document also make use of various BGP path attributes and extended communities (VRF Route Import Extended Community, Source AS Extended Community, and Route Target Extended Community) that were originally intended for use in VPN contexts. If these routes, attributes, and/or extended communities leak out into the wild, multicast data flows may be distributed in an unintended and/or unauthorized manner.
このドキュメントで説明されているプロトコルと手順は、本来VPNコンテキストでのみ使用するように設計されたタイプのルート（「MCAST-VPN」BGP SAFIを使用したルート）を利用しています。このドキュメントで説明するプロトコルと手順では、もともとVPNコンテキストでの使用を目的としたさまざまなBGPパス属性と拡張コミュニティ（VRFルートインポート拡張コミュニティ、ソースAS拡張コミュニティ、ルートターゲット拡張コミュニティ）も利用しています。これらのルート、属性、および/または拡張コミュニティが実際に流出した場合、マルチキャストデータフローが意図しない方法や許可されていない方法で配布される可能性があります。
When VPNs are provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of the VPN routes, making it difficult to cause a route to be distributed to and imported by a VRF that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN. In GTM, some of these protections against improper distribution/import of the routes is lost -- import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables.
VPNがプロビジョニングされると、各VRFにはインポートRTとエクスポートRTが設定されます。これらのRTは、VPNルートの配布とインポートを制限するため、そのルートのインポートが許可されていないVRFにルートを配布してインポートすることは困難です。さらに、VPNルートは「通常のインターネットルート」（つまり、非VPNルート）と一緒に「グローバルテーブル」に入らず、非VPNルートはVPN内のマルチキャストデータのフローに影響を与えません。 GTMでは、ルートの不適切な配布/インポートに対するこれらの保護の一部が失われています。ルートのインポートはVRFに制限されておらず、VRF間のルートの配布を制御するRTインフラストラクチャは、ルートがグローバルテーブルにインポートされます。
Internet Service Providers often make extensive use of BGP extended communities, sometimes adding, deleting, and/or modifying a route's extended communities as the route is distributed throughout the network. Care should be taken to avoid deleting or modifying the VRF Route Import Extended Community and Source AS Extended Community. Incorrect manipulation of these extended communities may result in multicast streams being lost or misrouted.
インターネットサービスプロバイダーは、多くの場合、BGP拡張コミュニティを広範囲に使用します。ルートがネットワーク全体に分散されると、ルートの拡張コミュニティが追加、削除、または変更される場合があります。 VRFルートインポート拡張コミュニティとソースAS拡張コミュニティを削除または変更しないように注意してください。これらの拡張コミュニティの不正な操作により、マルチキャストストリームが失われたり、誤ってルーティングされたりする可能性があります。
The procedures of this document require certain BGP routes to carry IP multicast group addresses. Generally, such group addresses are only valid within a certain scope. If a BGP route containing a group address is distributed outside the boundaries where the group address is meaningful, unauthorized distribution of multicast data flows may occur.
このドキュメントの手順では、IPマルチキャストグループアドレスを伝送するために特定のBGPルートが必要です。通常、このようなグループアドレスは特定のスコープ内でのみ有効です。グループアドレスを含むBGPルートが、グループアドレスが意味を持つ境界の外に配布される場合、マルチキャストデータフローの不正な配布が発生する可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNでのマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、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, DOI 10.17487/RFC6514, 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、DOI 10.17487 / RFC6514、2012年2月、< http://www.rfc-editor.org/info/rfc6514>。
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <http://www.rfc-editor.org/info/rfc6515>.
[RFC6515] Aggarwal、R。およびE. Rosen、「マルチキャストVPNのBGPアップデートにおけるIPv4およびIPv6インフラストラクチャアドレス」、RFC 6515、DOI 10.17487 / RFC6515、2012年2月、<http://www.rfc-editor.org/ info / rfc6515>。
[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, draft-ietf-idr-add-paths-12, November 2015.
[パスの追加] Walton、D.、Retana、A.、Chen、E.、J。Scudder、「BGPでの複数のパスのアドバタイズ」、Work in Progress、draft-ietf-idr-add-paths-12、 2015年11月。
[MVPN-extranet] Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-04, November 2015.
[MVPN-extranet] Rekhter、Y.、Rosen、E.、Aggarwal、R.、Cai、Y。、およびT. Morin、「BGP / IP MPLS VPNでのエクストラネットマルチキャスト」、Work in Progress、draft-ietf-bess -mvpn-extranet-04、2015年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、DOI 10.17487 / RFC4601 、2006年8月、<http://www.rfc-editor.org/info/rfc4601>。
[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, DOI 10.17487/RFC4684, 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、DOI 10.17487 / RFC4684、2006年11月、<http://www.rfc-editor.org/info/rfc4684>。
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008, <http://www.rfc-editor.org/info/rfc5294>.
[RFC5294] Savola、P。およびJ. Lingard、「Host Threats to Protocol Independent Multicast（PIM）」、RFC 5294、DOI 10.17487 / RFC5294、2008年8月、<http://www.rfc-editor.org/info/ rfc5294>。
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.
[RFC6368] Marques、P.、Raszuk、R.、Patel、K.、Kumaki、K。、およびT. Yamagata、「BGP / MPLS IP仮想プライベートネットワーク（VPN）のプロバイダー/カスタマーエッジプロトコルとしての内部BGP」 、RFC 6368、DOI 10.17487 / RFC6368、2011年9月、<http://www.rfc-editor.org/info/rfc6368>。
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <http://www.rfc-editor.org/info/rfc7524>.
[RFC7524] Rekhter、Y.、Rosen、E.、Aggarwal、R.、Morin、T.、Grosclaude、I.、Leymann、N。、およびS. Saad、「エリア間ポイントツーマルチポイント（P2MP）セグメント化ラベルスイッチドパス（LSP）」、RFC 7524、DOI 10.17487 / RFC7524、2015年5月、<http://www.rfc-editor.org/info/rfc7524>。
[RTC_without_RTs] Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route Target Constrained Distribution of Routes with no Route Targets", Work in Progress, draft-ietf-idr-rtc-no-rt-04, November 2015.
[RTC_without_RTs] Rosen、E.、Ed。、Patel、K.、Haas、J.、and R. Raszuk、 "Route Target Constrained Distribution of Routes with no route targets"、Work in Progress、draft-ietf-idr-rtc -no-rt-04、2015年11月。
Acknowledgments
謝辞
The authors and contributors would like to thank Rahul Aggarwal, Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas and comments.
著者と寄稿者は、Rahul Aggarwal、Huajin Jeng、Hui Ni、Yakov Rekhter、およびSamir Saadのアイデアとコメントに感謝します。
Contributors
貢献者
Jason Schiller Google Suite 400 1818 Library Street Reston, Virginia 20190 United States
Jason Schiller Google Suite 400 1818 Library Street Reston、Virginia 20190アメリカ
Email: jschiller@google.com
Zhenbin Li Huawei Technologies Huawei Blvd., No.156 Beiqing Rd. Beijing 100095 China
Zはビンl IH UAはテクノロジーhu Aはブルバード、no.156 be i青RD北京100095中国
Email: lizhenbin@huawei.com
Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China
ウェイメンG ZT E株式会社no.50ソフトウェアアベニュー、Y U Huatai地区NaN京中国
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China
くい わんｇ Ｚて こｒぽらちおん の。５０ そｆとぁれ あゔぇぬえ、 ゆふあたい ぢｓｔりｃｔ なんじんｇ ちな
Email: wang.cui1@zte.com.cn
Shunwan Zhuang Huawei Technologies Huawei Blvd., No.156 Beiqing Rd. Beijing 100095 China
Shu N Wan Z黄H UAはテクノロジーhu AはBlvd.、no。156 be i青RD北京100095中国
Email: zhuangshunwan@huawei.com
Authors' Addresses
著者のアドレス
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States
Zhaohui Zhang Juniper Networks、Inc. 10 Technology Park Drive Westford、Massachusetts 01886アメリカ
Email: zzhang@juniper.net
Lenny Giuliano Juniper Networks, Inc. 2251 Corporate Park Drive Herndon, Virginia 20171 United States
Lenny Giuliano Juniper Networks、Inc. 2251 Corporate Park Drive Herndon、Virginia 20171アメリカ
Email: lenny@juniper.net
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States
Eric C.Rosen（編集者）Juniper Networks、Inc. 10 Technology Park Drive Westford、Massachusetts 01886米国
Email: erosen@juniper.net
Karthik Subramanian Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 United States
Karthik Subramanian Cisco Systems、Inc. 170 Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: kartsubr@cisco.com
Dante J. Pacella Verizon 22001 Loudoun County Parkway Ashburn, Virginia 95134 United States
Dante J. Pacella Verizon 22001 Loudoun County Parkway Ashburn、Virginia 95134アメリカ
Email: dante.j.pacella@verizonbusiness.com