RFC 7740 - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7740
タイトル : RFC 7740 - 入力レプリケーションを使用したマルチポイントツーマルチポイント（MP2MP）プロバイダートンネルの部分メッシュのシミュレーション
翻訳編集 : 自動生成

[要約] 要約： RFC 7740は、Ingress Replicationを使用して、Multipoint-to-Multipoint（MP2MP）プロバイダトンネルの部分メッシュをシミュレートする方法について説明しています。目的：このRFCの目的は、MP2MPプロバイダトンネルの部分メッシュを効果的にシミュレートするための手法を提供することです。

Internet Engineering Task Force (IETF)                          Z. Zhang
Request for Comments: 7740                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                              A. Dolganow
                                                          Alcatel-Lucent
                                                            January 2016

Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication

入力レプリケーションを使用したマルチポイントツーマルチポイント（MP2MP）プロバイダートンネルの部分メッシュのシミュレーション

Abstract

概要

RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.

RFC 6513（「MPLS / BGP IP VPNでのマルチキャスト」）には、マルチポイントツーマルチポイント（MP2MP）トンネルの部分メッシュを使用して、双方向の顧客マルチキャストフローをサポートする方法が記載されています。このドキュメントでは、MP2MPトンネルの部分メッシュをイングレスレプリケーションを使用してシミュレートする方法を指定します。このソリューションにより、サービスプロバイダーは、イングレスレプリケーションを使用して、VPNカスタマーに透過的な双方向マルチキャストサービスを提供できます。

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/rfc7740.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7740で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Control State . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Forwarding State  . . . . . . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two methods of carrying Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow traffic over a provider core without using the core as the Rendezvous Point Link (RPL) or requiring Designated Forwarder election.

RFC 6513のセクション11.2（「パーティション化されたPEのセット」）は、コアをRendezvous Point Link（RPL）として使用することなく、またはプロバイダーコアを介して双方向PIM（BIDIR-PIM）[RFC5015] C-flowトラフィックを伝送する2つの方法を説明しています。指定フォワーダー選挙。

With these two methods, all Provider Edges (PEs) of a particular VPN are separated into partitions, with each partition being all the PEs that elect the same PE as the Upstream PE with respect to the C-RPA (the Rendezvous Point Address in the customer's address space). A PE must discard bidirectional C-flow traffic from PEs that are not in the same partition as the PE itself.

これらの2つの方法では、特定のVPNのすべてのプロバイダーエッジ（PE）がパーティションに分割され、各パーティションは、C-RPA（内のランデブーポイントアドレス）に関してアップストリームPEと同じPEを選出するすべてのPEです。顧客のアドレス空間）。 PEは、PE自体と同じパーティションにないPEからの双方向Cフロートラフィックを破棄する必要があります。

In particular, Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP P-Tunnels") guarantees the above discard behavior without using an extra PE Distinguisher Label by having all PEs in the same partition join a single MP2MP tunnel dedicated to that partition and use it to transmit traffic. All traffic arriving on the tunnel will be from PEs in the same partition, so it will be always accepted.

特に、RFC 6513のセクション11.2.3（「MP2MP Pトンネルの部分メッシュ」）は、同じパーティション内のすべてのPEをそのパーティション専用の単一のMP2MPトンネルに参加させることにより、追加のPE識別ラベルを使用せずに上記の破棄動作を保証しますトラフィックの送信に使用します。トンネルに到着するすべてのトラフィックは、同じパーティション内のPEからのものであるため、常に受け入れられます。

RFC 6514 specifies BGP encodings and procedures used to implement Multicast VPN (MVPN) as specified in RFC 6513, while the details related to MP2MP tunnels are specified in [RFC7582].

RFC 6514は、RFC 6513で指定されているようにマルチキャストVPN（MVPN）を実装するために使用されるBGPエンコーディングと手順を指定していますが、MP2MPトンネルに関する詳細は[RFC7582]で指定されています。

RFC 7582 assumes that an MP2MP P-tunnel is realized either via BIDIR-PIM [RFC5015] or via MP2MP mLDP (Multipoint extensions for LDP) [RFC6388]. Each would require signaling and state not just on PEs, but on the P routers as well. This document describes how the MP2MP tunnel can be simulated with a mesh of P2MP tunnels, each of which is instantiated by Ingress Replication (IR) [RFC6513] [RFC6514]. The procedures in this document are different from the procedures that are used to set up the mesh of Ingress Replication tunnels as described in RFC 6514; the procedures in this document do not require each PE on the MP2MP tunnel to send a Selective P-Multicast Service Interface (S-PMSI) auto-discovery route (A-D route) for the P2MP tunnel that the PE is the root for, nor do they require each PE to send a Leaf A-D route to the root of each P2MP tunnel in the mesh.

RFC 7582は、MP2MP PトンネルがBIDIR-PIM [RFC5015]またはMP2MP mLDP（LDPのマルチポイント拡張）[RFC6388]のいずれかによって実現されることを前提としています。それぞれは、PEだけでなくPルータでもシグナリングと状態を必要とします。このドキュメントでは、MP2MPトンネルをP2MPトンネルのメッシュでシミュレートする方法について説明します。各メッシュは、Ingress Replication（IR）[RFC6513] [RFC6514]によってインスタンス化されます。このドキュメントの手順は、RFC 6514で説明されている入力レプリケーショントンネルのメッシュを設定するために使用される手順とは異なります。このドキュメントの手順では、PEがルートであるP2MPトンネルの選択的Pマルチキャストサービスインターフェイス（S-PMSI）自動検出ルート（ADルート）を送信するために、MP2MPトンネルの各PEを必要としません。メッシュ内の各P2MPトンネルのルートにリーフADルートを送信するように各PEに要求します。

Because it uses Ingress Replication, this scheme has both the advantages and the disadvantages of Ingress Replication in general.

Ingress Replicationを使用するため、このスキームには、一般的にIngress Replicationの長所と短所があります。

1.1. Terminology

1.1. 用語

This document uses terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582].

このドキュメントでは、[RFC5015]、[RFC6513]、[RFC6514]、および[RFC7582]の用語を使用しています。

1.2. Requirements Language

1.2. 要件言語

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]で説明されているように解釈されます。

2. Operation

2. 操作

In the following sections, the originator of an S-PMSI A-D route or Leaf A-D route is determined from the "originating router's IP address" field of the corresponding route.

以下のセクションでは、S-PMSI A-DルートまたはリーフA-Dルートの発信者は、対応するルートの「発信元ルーターのIPアドレス」フィールドから決定されます。

2.1. Control State

2.1. 制御状態

If a PE, say PEx, is connected to a site of a given VPN and PEx's next-hop interface to some C-RPA is a VPN Routing and Forwarding (VRF) interface, then PEx MUST advertise a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether it has any local BIDIR-PIM join states corresponding to the C-RPA learned from its Customer Edges (CEs). It MAY also advertise one or more (C-*,C-G-BIDIR) S-PMSI A-D routes, if selective distribution trees are needed for those C-G-BIDIR groups and the corresponding C-RPA is in the site that the PEx connects to. For example, the (C-*,C-G-BIDIR) S-PMSI A-D routes could be triggered when the (C-*,C-G-BIDIR) traffic rate goes above a threshold (this may require measuring the traffic in both directions, due to the nature of BIDIR-PIM), and fan-out could also be taken into account.

PE、たとえばPExが特定のVPNのサイトに接続されており、一部のC-RPAへのPExのネクストホップインターフェイスがVPNルーティングおよび転送（VRF）インターフェイスである場合、PExは（C-*、C- * -BIDIR）カスタマーエッジ（CE）から学習したC-RPAに対応するローカルBIDIR-PIM結合状態があるかどうかに関係なく、S-PMSI ADルート。また、それらのC-G-BIDIRグループに選択的な配布ツリーが必要であり、対応するC-RPAがPExが接続するサイトにある場合、1つ以上の（C-*、C-G-BIDIR）S-PMSI A-Dルートをアドバタイズする場合があります。たとえば、（C-*、CG-BIDIR）S-PMSI ADルートは、（C-*、CG-BIDIR）トラフィックレートがしきい値を超えるとトリガーされます（これには、双方向のトラフィックを測定する必要がある場合があるため、 BIDIR-PIM）の性質に合わせて、ファンアウトも考慮することができます。

The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with tunnel type set to Ingress Replication, with the Leaf Information Required flag set, with a downstream allocated MPLS label that other PEs in the same partition MUST use when sending relevant C-BIDIR flows to this PE, and with the Tunnel Identifier field in the PTA set to a routable address of the originator. This specification does not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE (note that other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET]).

S-PMSI ADルートには、トンネルタイプがIngress Replicationに設定され、リーフ情報が必要なフラグが設定されたPMSIトンネル属性（PTA）が含まれ、同じパーティション内の他のPEが関連するC- BIDIRはこのPEに流れ、PTAのTunnel Identifierフィールドは発信者のルーティング可能なアドレスに設定されます。この仕様は、（C-*、C-*-BIDIR）と（C-*、CG-BIDIR）によって共有されるラベルなど、Pトンネル間でのラベルの共有を妨げません。特定のPE（[MVPN-EXTRANET]など、他の仕様ではそれをどのように実行できるかに制約があることに注意してください）。

If some other PE, PEy, receives and imports into one of its VRFs any (C-*,C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel and the VRF has any local BIDIR-PIM join state that PEy has received from its CEs and if PEy chooses PEx as its Upstream PE with respect to the C-RPA for those states, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-*-BIDIR) S-PMSI A-D route from PEx before, then upon receiving in the VRF any local BIDIR-PIM join state from its CEs with PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise a Leaf A-D route.

他のPE（PEy）がVRFの1つを受信してインポートする場合、PTAがIR Pトンネルを指定し、VRFがローカルBIDIR-PIMに参加している（C-*、C-*-BIDIR）S-PMSI ADルートPEyがそのCEから受信した状態であり、PEyがそれらの状態のC-RPAに関してアップストリームPEとしてPExを選択した場合、PEyはそれに応じてリーフADルートをアドバタイズする必要があります。または、PEyが以前にPExから（C-*、C-*-BIDIR）S-PMSI ADルートを受信してVRFの1つにインポートした場合、VRFでそのCEからローカルBIDIR-PIM結合状態を受信するとPExはこれらの州のC-RPAのアップストリームPEであり、PEyはリーフADルートをアドバタイズする必要があります。

The encoding of the Leaf A-D route is as specified in RFC 6514, except that the Route Targets are set to the same value as in the corresponding S-PMSI A-D route so that the Leaf A-D route will be imported by all VRFs that import the corresponding S-PMSI A-D route. This is irrespective of whether or not the originator of the S-PMSI A-D route is the Upstream PE from a receiving PE's perspective. The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx, so that when traffic arrives with that label, the traffic can associate with the partition (represented by the PEx). This specification does not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) Leaf A-D route originated by a given PE (note that other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET]).

リーフADルートのエンコードはRFC 6514で指定されているとおりですが、対応するS-PMSI ADルートと同じ値にルートターゲットが設定されているため、対応するインポートするすべてのVRFによってリーフADルートがインポートされます。 S-PMSI ADルート。これは、S-PMSI A-Dルートの発信者が受信側PEの観点からのアップストリームPEであるかどうかには関係ありません。 PEyによって開始されたリーフA-DルートのPTA内のラベルは、PEx専用に割り当てられる必要があります。これにより、トラフィックがそのラベルで到着したときに、トラフィックはパーティション（PExで表される）に関連付けることができます。この仕様は、ラベルが（C-*、C-*-BIDIR）と（C-*、CG-BIDIR）によって共有されるなど、Pトンネル間でのラベルの共有を防止しません。 PE（他の仕様では、[MVPN-EXTRANET]など、それを行う方法に制約があることに注意してください）。

Note that RFC 6514 requires that a PE or an ASBR (Autonomous System Border Router) take no action with regard to a Leaf A-D route unless that Leaf A-D route carries an IP-address-specific Route Target identifying the PE/ASBR. This document removes that requirement when the route key of a Leaf A-D route identifies a (C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI.

RFC 6514では、PEまたはASBR（Autonomous System Border Router）が、リーフA-DルートがPE / ASBRを識別するIPアドレス固有のルートターゲットを運ぶ場合を除き、リーフA-Dルートに関して何のアクションも実行しないことを要求しています。このドキュメントでは、リーフA-Dルートのルートキーが（C-*、C-*-BIDIR）または（C-*、C-G-BIDIR）S-PMSIを識別する場合の要件を削除します。

To speed up convergence (so that PEy starts receiving traffic from its new Upstream PE immediately instead of waiting until the new Leaf A-D route corresponding to the new Upstream PE is received by sending PEs), PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA. With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a different label; the traffic in the latter case will be discarded.

コンバージェンスを高速化するため（PEは、PEを送信して新しいアップストリームPEに対応する新しいリーフADルートが受信されるまで待機するのではなく、新しいアップストリームPEからトラフィックの受信をすぐに開始するため）、リーフADルートをアドバタイズしてもよい（MAY） C-RPAに関してPPEをアップストリームPEとして選択しないでください。これにより、すべてのPEからトラフィックを受信しますが、選択したアップストリームPEに対応するラベルが付いたものもあれば、別のラベルが付いたものもあります。後者の場合のトラフィックは破棄されます。

Similar to the (C-*,C-*-BIDIR) case, if PEy receives and imports into one of its VRFs any (C-*,C-G-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, PEy chooses PEx as its Upstream PE with respect to the C-RPA, and it has corresponding local (C-*,C-G-BIDIR) join state that it has received from its CEs in the VRF, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route before, then upon receiving its local (C-*,C-G-BIDIR) join state from its CEs in the VRF, it MUST advertise a Leaf A-D route.

（C-*、C-*-BIDIR）の場合と同様に、PEyがVRFの1つを受信してインポートする場合、PTAがIR Pトンネルを指定する（C-*、CG-BIDIR）S-PMSI ADルートのいずれか、 PEyは、C-RPAに関するアップストリームPEとしてPExを選択し、対応するローカル（C-*、CG-BIDIR）結合状態を持ち、VRF内のCEから受信したため、PEyはリーフADルートを応答。または、PEyが以前に（C-*、CG-BIDIR）S-PMSI ADルートを受信してVRFの1つにインポートした場合、そのローカル（C-*、CG-BIDIR）結合状態をそのCEから受信するとVRFは、リーフADルートをアドバタイズする必要があります。

The encoding of the Leaf A-D route is similar to the (C-*,C-*-BIDIR) case. Similarly, PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA.

Leaf A-Dルートのエンコーディングは、（C-*、C-*-BIDIR）の場合と似ています。同様に、PEyは、C-RPAに関してアップストリームPEとしてPExを選択しなくても、リーフA-Dルートをアドバタイズできます（MAY）。

PEy MUST withdraw the corresponding Leaf A-D route if any of the following conditions are true:

次の条件のいずれかに該当する場合、PEyは対応するリーフA-Dルートを撤回する必要があります。

o the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is withdrawn.

o （C-*、C-*-BIDIR）または（C-*、C-G-BIDIR）S-PMSI A-Dルートが撤回されました。

o PEy no longer chooses the originator PEx as its Upstream PE with respect to C-RPA and PEy only advertises Leaf A-D routes in response to its Upstream PE's S-PMSI A-D route.

o PEyはC-RPAに関してアップストリームPEとして発信者PExを選択しなくなり、PEyはそのアップストリームPEのS-PMSI A-Dルートに応答してリーフA-Dルートのみをアドバタイズします。

o if relevant local join state is pruned.

o 関連するローカル結合状態がプルーニングされている場合。

2.2. Forwarding State

2.2. 転送状態

The specification regarding forwarding state in this section matches the "When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is a 'Match for Reception'" rules for the "Flat Partitioning" method in [RFC7582], except that the rules about (C-*,C-*) are not applicable, because this document requires that (C-*,C-*-BIDIR) S-PMSI A-D routes are always originated for a VPN that supports C-BIDIR flows.

このセクションの転送状態に関する仕様は、[RFC7582の「フラットパーティショニング」メソッドの「S-PMSIが「送信用の一致」の場合」および「S-PMSIが「受信用の一致」の場合」のルールと一致します。 ]、ただし、このドキュメントでは（C-*、C-*-BIDIR）S-PMSI ADルートがCをサポートするVPNに対して常に発信される必要があるため、（C-*、C- *）に関するルールは適用されません。 -BIDIRフロー。

For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to the C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, PEy maintains a (C-*,C-G-BIDIR) forwarding state in the VRF, with the Ingress Replication provider tunnel leaves being the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN Network Layer Reachability Information (NLRI) of the (C-*,C-G-BIDIR) S-PMSI A-D route advertised by the Upstream PE.

PEy自体がS-PMSI ADルートをアドバタイズする場合、PEyがC-RPAに関してアップストリームPEからVRFの1つを受信してインポートする（C-*、CG-BIDIR）S-PMSI ADルートの場合VRF、PEyは、VRFで（C-*、CG-BIDIR）転送状態を維持します。入力レプリケーションプロバイダーのトンネルは、S-PMSI ADルートとすべての関連するリーフADルートの発信元です。関連するリーフA-Dルートは、ルートキーフィールドに、アップストリームPEによってアドバタイズされた（C-*、C-G-BIDIR）S-PMSI A-DルートのMCAST-VPNネットワーク層到達可能性情報（NLRI）と同じ情報が含まれているルートです。

For the (C-*,C-*-BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to a C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, it maintains appropriate forwarding states in the VRF for the ranges of bidirectional groups for which the C-RPA is responsible. The provider tunnel leaves are the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN NLRI of the (C-*,C-*-BIDIR) S-PMSI A-D route advertised by the Upstream PE. This is for the so-called "Sender Only Branches" where a router only has data to send upstream towards C-RPA but no explicit join state for a particular bidirectional group. Note that the traffic must be sent to all PEs (not just the Upstream PE) in the partition, because they may have specific (C-*,C-G-BIDIR) join states that this PEy is not aware of, while there are no corresponding (C-*,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes.

PEy自体がS-PMSI ADをアドバタイズする場合、PEyがC-RPAに関してアップストリームPEからVRFの1つを受信してインポートする（C-*、C-*-BIDIR）S-PMSI ADルートの場合VRF内のルートでは、C-RPAが担当する双方向グループの範囲について、VRF内で適切な転送状態を維持します。プロバイダートンネルリーフは、S-PMSI A-Dルートおよびすべての関連するリーフA-Dルートの発信元です。関連するリーフA-Dルートは、ルートキーフィールドに、アップストリームPEによってアドバタイズされる（C-*、C-*-BIDIR）S-PMSI A-DルートのMCAST-VPN NLRIと同じ情報が含まれるルートです。これは、いわゆる「送信側のみのブランチ」用で、ルーターには、C-RPAに向けてアップストリームに送信するデータのみがあり、特定の双方向グループの明示的な参加状態はありません。トラフィックは、パーティション内のすべてのPE（アップストリームPEだけでなく）に送信する必要があることに注意してください。これらのPEは、このPEyが認識していない特定の（C-*、CG-BIDIR）結合状態を持っている可能性があるためです。（C-*、CG-BIDIR）S-PMSI ADおよびLeaf ADルート。

For a (C-*,C-G-BIDIR) join state that a PEy has received from its CEs in a VRF, if there is no corresponding (C-*,C-G-BIDIR) S-PMSI A-D route from its Upstream PE in the VRF, PEy maintains a corresponding forwarding state in the VRF, with the provider tunnel leaves being the originators of the (C-*,C-*-BIDIR) S-PMSI A-D route and all relevant Leaf A-D routes (same as the "Sender Only Branches" case above). The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN NLRI of the (C-*,C-*-BIDIR) S-PMSI A-D route originated by the Upstream PE. If there is also no (C-*,C-*-BIDIR) S-PMSI A-D route from its Upstream PE, then the provider tunnel has an empty set of leaves, and PEy does not forward relevant traffic across the provider network.

PEがVRFのCEから受信した（C-*、CG-BIDIR）参加状態の場合、対応する（C-*、CG-BIDIR）S-PMSI ADルートがアップストリームPEからVRF、PEyはVRFで対応する転送状態を維持し、プロバイダートンネルリーフは（C-*、C-*-BIDIR）S-PMSI ADルートとすべての関連するリーフADルート（「送信者上記の分岐のみの場合）。関連するリーフA-Dルートは、ルートキーフィールドに、アップストリームPEによって発信された（C-*、C-*-BIDIR）S-PMSI A-DルートのMCAST-VPN NLRIと同じ情報が含まれるルートです。アップストリームPEからの（C-*、C-*-BIDIR）S-PMSI A-Dルートもない場合、プロバイダートンネルには空のリーフセットがあり、PEyはプロバイダーネットワークを介して関連するトラフィックを転送しません。

3. Security Considerations

3. セキュリティに関する考慮事項

This document raises no new security issues. Security considerations for the base protocol are covered in [RFC6513] and [RFC6514].

このドキュメントでは、新しいセキュリティの問題は発生しません。基本プロトコルのセキュリティに関する考慮事項は、[RFC6513]と[RFC6514]でカバーされています。

4. References

4. 参考文献

4.1. Normative References

4.1. 引用文献

[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>。

[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>。

[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <http://www.rfc-editor.org/info/rfc7582>.

[RFC7582] Rosen、E.、Wijnands、IJ。、Cai、Y。、およびA. Boers、「Multicast Virtual Private Network（MVPN）：Using Bidirectional P-Tunnels」、RFC 7582、DOI 10.17487 / RFC7582、2015年7月、 <http://www.rfc-editor.org/info/rfc7582>。

4.2. Informative References

4.2. 参考引用

[MVPN-EXTRANET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-06, January 2016.

[MVPN-EXTRANET] Rekhter、Y.、Ed。、Rosen、E.、Ed。、Aggarwal、R.、Cai、Y。、およびT. Morin、「BGP / IP MPLS VPNでのエクストラネットマルチキャスト」、作業中、draft-ietf-bess-mvpn-extranet-06、2016年1月。

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.

[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<http：/ /www.rfc-editor.org/info/rfc5015>。

[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.

[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、DOI 10.17487 / RFC6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。

Acknowledgements

謝辞

We would like to thank Eric Rosen for his comments and suggestions for some text used in the document.

ドキュメントで使用されているいくつかのテキストに対するコメントと提案を提供してくれたEric Rosenに感謝します。

Authors' Addresses

著者のアドレス

Zhaohui Zhang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 United States

Zhaohui Zhang Juniper Networks 10 Technology Park Dr. Westford、MA 01886アメリカ

   Email: zzhang@juniper.net

Yakov Rekhter Juniper Networks

Andrew Dolganow Alcatel-Lucent 600 March Rd. Ottawa, ON K2K 2E6 Canada

アンドリュードルガノウアルカテルルーセント600 3月路。 ONK2K 2E6カナダオタワ

   Email: andrew.dolganow@alcatel-lucent.com