[要約] RFC 7900は、BGP/IP MPLS VPNsにおけるExtranet Multicastの実装に関するガイドラインです。このRFCの目的は、Extranet Multicastの設計と展開に関するベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) Y. Rekhter, Ed.
Request for Comments: 7900 E. Rosen, Ed.
Updates: 6513, 6514, 6625 Juniper Networks, Inc.
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan
Y. Cai
Alibaba Group
T. Morin
Orange
June 2016
Extranet Multicast in BGP/IP MPLS VPNs
BGP / IP MPLS VPNでのエクストラネットマルチキャスト
Abstract
概要
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.
以前のRFCは、IPマルチキャストトラフィックがBGP / MPLS IP VPN（仮想プライベートネットワーク）内のあるサイトから別のサイトに移動できるようにするために必要な手順を指定しています。ただし、送信元が1つのVPNにあるマルチキャストトラフィックを、別のVPNにあるシステムで受信できるようにすることが望ましい場合があります。これは、「マルチキャストVPN（MVPN）エクストラネット」と呼ばれます。このドキュメントは、エクストラネットMVPNサービスを提供するために必要な手順を指定することにより、RFC 6513、6514、および6625を更新します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7900.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7900で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 ....................................................4
1.1. Terminology ................................................4
1.2. Scope ......................................................7
1.2.1. Customer Multicast Control Protocols ................7
1.2.2. Provider Multicast Control Protocols ................7
1.3. Clarification on Use of Route Distinguishers ...............8
1.4. Overview ...................................................9
2. Extranets and Overlapping Address Spaces .......................12
2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows ......14
2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ..........16
2.3. Preventing Misdelivery in These Scenarios .................18
2.3.1. Do Not Deliver Packets from the Wrong P-tunnel .....18
2.3.2. Policies to Prevent Ambiguity on a P-Tunnel ........20
3. Extranet Transmission Models ...................................21
3.1. Transmitting an Extranet C-Flow on a Single PMSI ..........21
3.1.1. Without Extranet Separation ........................22
3.1.2. With Extranet Separation ...........................22
3.2. Transmitting an Extranet C-Flow over Multiple PMSIs .......23
4. Distribution of Routes That Match C-S/C-RP Addresses ...........23
4.1. UMH-Eligible Routes .......................................23
4.1.1. Extranet Separation ................................24
4.2. Distribution of Unicast Routes Matching C-RPs and DRs .....25
4.3. Route Targets and Ambiguous UMH-Eligible Routes ...........26
4.4. Dynamically Marking Extranet Routes .......................27
4.4.1. The Extranet Source Extended Community .............27
4.4.2. Distribution of Extranet Source Extended
Community ..........................................29
4.5. The Extranet Separation Extended Community ................30
5. Origination and Distribution of BGP A-D Routes .................30
5.1. Route Targets of UMH-Eligible Routes and A-D Routes .......30
5.2. Considerations for Particular Inclusive Tunnel Types ......33
5.2.1. RSVP-TE P2MP or Ingress Replication ................33
5.2.2. Ingress Replication ................................34
6. When PIM Is the PE-PE C-Multicast Control Plane ................35
6.1. Provisioning VRFs with RTs ................................36
6.1.1. Incoming and Outgoing Extranet RTs .................36
6.1.2. UMH-Eligible Routes and RTs ........................37
6.1.3. PIM C-Instance Reverse Path Forwarding
Determination ......................................37
6.2. "Single PMSI per C-Flow" Model ............................38
6.2.1. Forming the MI-PMSIs ...............................38
6.2.2. S-PMSIs ............................................41
6.2.3. Sending PIM Control Packets ........................42
6.2.4. Receiving PIM Control Packets ......................43
6.2.5. Sending and Receiving Data Packets .................43
6.3. "Multiple PMSIs per C-Flow" Model .........................43
6.3.1. Forming the MI-PMSIs ...............................44
7. When BGP Is the PE-PE C-Multicast Control Plane ................46
7.1. Originating C-Multicast Routes ............................46
7.2. Originating A-D Routes without Extranet Separation ........47
7.2.1. Intra-AS I-PMSI A-D Routes .........................47
7.2.2. S-PMSI A-D Routes ..................................47
7.2.3. Source Active A-D Routes ...........................48
7.2.3.1. When Inter-Site Shared Trees Are Used .....48
7.2.3.2. When Inter-Site Shared Trees Are
Not Used ..................................49
7.3. Originating A-D Routes with Extranet Separation ...........49
7.3.1. Intra-AS I-PMSI A-D Routes .........................49
7.3.2. S-PMSI A-D Routes ..................................50
7.3.3. Source Active A-D Routes ...........................52
7.4. Determining the Expected P-Tunnel for a C-Flow ............52
7.4.1. (C-S,C-G) S-PMSI A-D Routes ........................54
7.4.2. (C-S,C-*) S-PMSI A-D Routes ........................54
7.4.3. (C-*,C-G) S-PMSI A-D Routes ........................55
7.4.4. (C-*,C-*) S-PMSI A-D Routes ........................56
7.4.5. I-PMSI A-D Routes ..................................56
7.5. Packets Arriving from the Wrong P-Tunnel ..................57
8. Multiple Extranet VRFs on the Same PE ..........................57
9. IANA Considerations ............................................58
10. Security Considerations .......................................59
11. References ....................................................61
11.1. Normative References .....................................61
11.2. Informative References ...................................62
Acknowledgments ...................................................64
Contributors ......................................................64
Authors' Addresses ................................................65
Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as an "extranet Multicast VPN (MVPN)". This document specifies the procedures that are necessary in order to provide extranet MVPN functionality.
以前のRFC [RFC6513] [RFC6514]では、IPマルチキャストトラフィックがBGP / MPLS IP VPN（仮想プライベートネットワーク）内のあるサイトから別のサイトに移動できるようにするために必要な手順を指定しています。ただし、送信元が1つのVPNにあるマルチキャストトラフィックを、別のVPNにあるシステムで受信できるようにすることが望ましい場合があります。これは「エクストラネットマルチキャストVPN（MVPN）」と呼ばれます。このドキュメントでは、エクストラネットMVPN機能を提供するために必要な手順を説明しています。
This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.
このドキュメントは、エクストラネットMVPNサービスを提供するために必要な手順を指定することにより、RFC 6513、6514、および6625を更新します。
This document uses terminology from [RFC6513] and in particular uses the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513], and "A-D routes" for "auto-discovery routes".
このドキュメントでは、[RFC6513]の用語を使用し、特に[RFC6513]のセクション3.1で指定されている接頭辞「C-」と「P-」、および「自動検出ルート」の「A-Dルート」を使用します。
The term "Upstream Multicast Hop" (UMH) is used as defined in [RFC6513].
「アップストリームマルチキャストホップ」（UMH）という用語は、[RFC6513]で定義されているように使用されます。
The term "UMH-eligible route" is used to mean "route eligible for UMH determination", as defined in Section 5.1.1 of [RFC6513]. We will say that a given UMH-eligible route or unicast route "matches" a given IP address, in the context of a given Virtual Routing and Forwarding table (VRF), if the address prefix of the given route is the longest match in that VRF for the given IP address. We will sometimes say that a route "matches" a particular host if the route matches an IP address of the host.
[RFC6513]のセクション5.1.1で定義されているように、「UMH適格ルート」という用語は「UMH決定に適格なルート」を意味するために使用されます。特定のルートのアドレスプレフィックスがその中で最長の一致である場合、特定の仮想ルーティングおよび転送テーブル（VRF）のコンテキストで、特定のUMH適格ルートまたはユニキャストルートが特定のIPアドレスに「一致」すると言います。指定されたIPアドレスのVRF。ルートがホストのIPアドレスに一致する場合、そのルートは特定のホストに「一致する」と言うことがあります。
We follow the terminology of Section 3.2 of [RFC6625] when talking of a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route being "installed". That is, we say that an S-PMSI A-D route is "installed" (in a given VRF) if it has been selected by the BGP decision process as the preferred route for its Network Layer Reachability Information (NLRI). We also follow the terminology of Section 3.2 of [RFC6625] when saying that an S-PMSI A-D route has been "originated by a given PE"; this means that the given Provider Edge's (PE's) IP address is contained in the Originating Router's IP Address field in the NLRI of the route.
「選択的プロバイダーマルチキャストサービスインターフェース」（S-PMSI）のA-Dルートが「インストールされている」と言うときは、[RFC6625]のセクション3.2の用語に従います。つまり、S-PMSI A-Dルートがネットワークレイヤー到達可能性情報（NLRI）の優先ルートとしてBGP決定プロセスによって選択されている場合、（指定されたVRFに）「インストール」されていると言います。また、[RFC6625]のセクション3.2の用語に従い、S-PMSI A-Dルートが「指定されたPEによって発信された」と言います。これは、指定されたプロバイダーエッジ（PE）のIPアドレスが、ルートのNLRIの発信元ルーターのIPアドレスフィールドに含まれていることを意味します。
We use the following additional terminology and notation:
以下の追加の用語と表記法を使用します。
o Extranet C-source: a multicast source, in a given VPN, that is allowed by policy to send multicast traffic to receivers that are in other VPNs.
o エクストラネットCソース：ポリシーにより、他のVPNにある受信者にマルチキャストトラフィックを送信することが許可されている、特定のVPN内のマルチキャストソース。
o Extranet C-receiver: a multicast receiver, in a given VPN, that is allowed by policy to receive multicast traffic from extranet C-sources that are in other VPNs.
o エクストラネットCレシーバー：ポリシーにより、他のVPNにあるエクストラネットCソースからマルチキャストトラフィックを受信できる、特定のVPN内のマルチキャストレシーバー。
o Extranet C-flow: a multicast flow (with a specified C-source address and C-group address) with the following properties: its source is an extranet C-source, and it is allowed by policy to have extranet C-receivers.
o エクストラネットCフロー：次のプロパティを持つマルチキャストフロー（指定されたCソースアドレスとCグループアドレス）：ソースはエクストラネットCソースであり、ポリシーによってエクストラネットCレシーバーを持つことが許可されています。
o Extranet C-group: a multicast group address that is in the "Any-Source Multicast" (ASM) group address range and that is allowed by policy to have extranet C-sources and extranet C-receivers that are not all in the same VPN. Note that we will sometimes refer to "Source-Specific Multicast (SSM) C-group addresses" (i.e., C-group addresses in the SSM group address range) but will never call them "extranet C-groups".
o エクストラネットCグループ：「Any-Source Multicast」（ASM）グループアドレス範囲内にあり、すべて同じVPNにないエクストラネットCソースとエクストラネットCレシーバーを持つことがポリシーで許可されているマルチキャストグループアドレス。 「ソース固有のマルチキャスト（SSM）Cグループアドレス」（SSMグループアドレス範囲内のCグループアドレス）と呼ばれることもありますが、「エクストラネットCグループ」と呼ばれることはありません。
N.B.: Any source of traffic for an extranet C-group is considered to be an extranet C-source, and any receiver of traffic addressed to an extranet C-group is considered to be an extranet C-receiver.
注：エクストラネットCグループのトラフィックの送信元はエクストラネットCソースと見なされ、エクストラネットCグループにアドレス指定されたトラフィックの受信者はエクストラネットC受信者と見なされます。
o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet C-group; it is allowed by policy to receive PIM Register messages [RFC7761] from outside its VPN and to send multicast data packets to extranet C-receivers outside its VPN.
o エクストラネットC-RP：エクストラネットCグループのマルチキャストランデブーポイント（RP）。 VPNの外部からPIM Registerメッセージ[RFC7761]を受信し、VPNの外部のエクストラネットCレシーバーにマルチキャストデータパケットを送信することは、ポリシーによって許可されています。
o Host(C-S,A): the host (or, if C-S is an "anycast address", the set of hosts) denoted by the address C-S in the context of VPN-A. For example, if a particular C-source in VPN-A has address C-S, then Host(C-S,A) refers to that C-source.
o Host（C-S、A）：VPN-AのコンテキストでアドレスC-Sによって示されるホスト（または、C-Sが「エニーキャストアドレス」の場合は、ホストのセット）。たとえば、VPN-Aの特定のCソースにアドレスC-Sがある場合、Host（C-S、A）はそのCソースを参照します。
o "SAFI n" route: a BGP route whose Address Family Identifier (AFI) is either 1 (IPv4) or 2 (IPv6) and whose Subsequent Address Family Identifier (SAFI) is "n".
o "SAFI n"ルート：アドレスファミリ識別子（AFI）が1（IPv4）または2（IPv6）であり、その後のアドレスファミリ識別子（SAFI）が "n"であるBGPルート。
o PTA: PMSI Tunnel Attribute [RFC6514].
o PTA：PMSIトンネル属性[RFC6514]。
Note that a given extranet C-source is not necessarily allowed to transmit to every extranet C-receiver; policy determines which extranet C-sources are allowed to transmit to which extranet C-receivers. However, in the case of an extranet (ASM) C-group, all transmitters to the group are allowed to transmit to all the receivers of the group, and all the receivers of the group are allowed to receive from all transmitters to the group.
特定のエクストラネットCソースが必ずしもすべてのエクストラネットCレシーバーへの送信を許可されているわけではないことに注意してください。ポリシーは、どのエクストラネットCソースがどのエクストラネットCレシーバーへの送信を許可されるかを決定します。ただし、エクストラネット（ASM）Cグループの場合、グループへのすべてのトランスミッターはグループのすべてのレシーバーへの送信を許可され、グループのすべてのレシーバーはすべてのトランスミッターからグループへの受信を許可されます。
We say that a given VRF "contains" or "has" a multicast C-source (or that the C-source is "in" the VRF) if that C-source is in a site connected to that VRF and the VRF originates a UMH-eligible route (see Section 4) that matches the address of the C-source.
特定のVRFがマルチキャストCソースを「含む」または「持っている」（またはCソースがVRFの「中にある」）とは、そのCソースがそのVRFに接続されたサイトにあり、VRFがCソースのアドレスと一致するUMH適格ルート（セクション4を参照）。
We say that a given VRF "contains" or "has" a multicast C-receiver (or that the C-receiver is "in" the VRF) if that C-receiver is in a site connected to that VRF.
特定のVRFは、そのCRFがそのVRFに接続されたサイトにある場合、マルチキャストCレシーバーを「含む」または「持っている」（または、CレシーバーがVRFの「中にある」）と言います。
We say that a given VRF "contains" or "has" the C-RP for a given ASM group (or that the C-RP is "in" the VRF) if that C-RP is in a site connected to that VRF and the VRF originates a unicast route and a (possibly different, possibly the same) UMH-eligible route (see Section 4) whose respective address prefixes match the C-RP address.
C-RPがそのVRFに接続されたサイトにある場合、特定のVRFは特定のASMグループのC-RPを「含む」または「持っている」（またはC-RPがVRFの「中にある」） VRFは、ユニキャストルートと、それぞれのアドレスプレフィックスがC-RPアドレスと一致する（おそらく異なる、おそらく同じ）UMH適格ルート（セクション4を参照）を発信します。
[RFC6513] allows a set of "P-tunnels" (defined in Section 3.2 of [RFC6513]) to be aggregated together and transported via an outer P-tunnel; i.e., it allows for the use of hierarchical Label Switched Paths (LSPs) as P-tunnels. A two-level hierarchical LSP, for example, can be thought of as a set of "inner tunnels" aggregated into an outer tunnel. In this document, when we speak of a P-tunnel, we are always speaking of the innermost P-tunnel, i.e., of a P-tunnel at the lowest hierarchical level. P-tunnels are identified in the PMSI Tunnel attributes ("PTAs" in this document) [RFC6514] of BGP auto-discovery (A-D) routes. Two PTAs that have the same Tunnel Type and Tunnel Identifier fields but different MPLS label fields are thus considered to identify two different P-tunnels. (That is, for the purposes of this document, the MPLS label included in the PTA, if any, is considered to be part of the tunnel identifier.)
[RFC6513]を使用すると、[P-tunnels]（[RFC6513]のセクション3.2で定義）のセットを集約して、外部のPトンネルを介して転送できます。つまり、階層的なラベルスイッチドパス（LSP）をPトンネルとして使用できます。たとえば、2レベルの階層型LSPは、外部トンネルに集約された「内部トンネル」のセットと考えることができます。このドキュメントでは、Pトンネルについて話すときは、常に最も内側のPトンネル、つまり最下位階層レベルのPトンネルについて話しています。 Pトンネルは、BGP自動検出（A-D）ルートのPMSIトンネル属性（このドキュメントでは「PTA」）[RFC6514]で識別されます。したがって、同じトンネルタイプフィールドとトンネル識別子フィールドを持つが、MPLSラベルフィールドが異なる2つのPTAは、2つの異なるPトンネルを識別すると見なされます。 （つまり、このドキュメントの目的上、PTAに含まれているMPLSラベルは、もしあれば、トンネル識別子の一部と見なされます。）
We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D route contains (C-S,C-G) if its Multicast Source field contains C-S and its Multicast Group field contains C-G. If either or both of these fields are encoded as a wildcard, we will say that the NLRI contains (C-*,C-*) (both fields encoded as wildcards), (C-*,C-G) (Multicast Source field encoded as a wildcard), or (C-S,C-*) (Multicast Group field encoded as a wildcard).
マルチキャストソースフィールドにC-Sが含まれ、マルチキャストグループフィールドにC-Gが含まれている場合、BGP S-PMSI A-DルートまたはソースアクティブA-DルートのNLRIには（C-S、C-G）が含まれると言います。これらのフィールドのいずれかまたは両方がワイルドカードとしてエンコードされている場合、NLRIには（C-*、C- *）（両方のフィールドはワイルドカードとしてエンコードされています）、（C-*、CG）（マルチキャストソースフィールドは次のようにエンコードされています）ワイルドカード）、または（CS、C- *）（ワイルドカードとしてエンコードされたマルチキャストグループフィールド）。
We use the term "VPN security violation" to refer to any situation in which a packet is delivered to a particular VPN, even though, by policy, it should not be delivered to that VPN.
「VPNセキュリティ違反」という用語は、パケットが特定のVPNに配信される状況を指します。ただし、ポリシーにより、そのVPNには配信されるべきではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document presumes that the VPN customer is using PIM - Sparse Mode (PIM-SM) [RFC7761] as the multicast control protocol at the customer sites. PIM-SM may be used in either the ASM service model or the SSM service model; this document covers both cases. Support for other customer IP multicast control protocols (e.g., [RFC5015], PIM - Dense Mode) is outside the scope of this document. Support for the use of MPLS multicast control protocols (e.g., [RFC6388] [RFC4875]) by customer sites is also outside the scope of this document.
このドキュメントでは、VPNカスタマーがカスタマーサイトでマルチキャスト制御プロトコルとしてPIM-スパースモード（PIM-SM）[RFC7761]を使用していることを前提としています。 PIM-SMは、ASMサービスモデルまたはSSMサービスモデルのいずれかで使用できます。このドキュメントでは両方のケースについて説明します。他のお客様のIPマルチキャスト制御プロトコル（[RFC5015]、PIM-高密度モードなど）のサポートは、このドキュメントの範囲外です。顧客サイトによるMPLSマルチキャスト制御プロトコル（[RFC6388] [RFC4875]など）の使用のサポートも、このドキュメントの範囲外です。
When a VPN customer uses ASM, the customer routers need to be able to map from a C-group address to a C-RP address. These mappings can be provisioned in each router, or they can be discovered dynamically through protocols such as the Bootstrap Router (BSR) mechanism [RFC5059]. However, it cannot be assumed that such protocols will automatically work in the context of an extranet. Discussion of the use of such protocols in an extranet is outside the scope of this document.
VPNの顧客がASMを使用する場合、顧客のルーターはCグループアドレスからC-RPアドレスにマップできる必要があります。これらのマッピングは、各ルーターでプロビジョニングするか、ブートストラップルーター（BSR）メカニズム[RFC5059]などのプロトコルを介して動的に検出できます。ただし、そのようなプロトコルがエクストラネットのコンテキストで自動的に機能するとは限りません。エクストラネットでのこのようなプロトコルの使用に関する説明は、このドキュメントの範囲外です。
[RFC6513] allows either PIM or BGP to be used as the protocol for distributing customer multicast routing information. Except where otherwise specified, such as in Sections 6 and 7, the procedures of this document cover both cases.
[RFC6513]では、PIMまたはBGPのいずれかを、顧客のマルチキャストルーティング情報を配信するためのプロトコルとして使用できます。セクション6と7のように特に指定されている場合を除き、このドキュメントの手順は両方のケースをカバーしています。
[RFC4364] requires that every VRF be associated with one or more Route Distinguishers (RDs). Each VPN-IPv4 or VPN-IPv6 route that is exported from a particular VRF contains, in its NLRI, an RD that is associated with that VRF.
[RFC4364]では、すべてのVRFが1つ以上のルート識別子（RD）に関連付けられている必要があります。特定のVRFからエクスポートされる各VPN-IPv4またはVPN-IPv6ルートには、そのNLRIに、そのVRFに関連付けられているRDが含まれています。
[RFC4364] allows a given RD to be associated with more than one VRF, as long as all the VRFs associated with that RD belong to the same VPN. However, in the most common deployment model, each RD is associated with one and only one VRF. [RFC6513] and [RFC6514] presuppose this deployment model. That is, [RFC6513] and [RFC6514] presuppose that every RD is associated with one and only one VRF. We will call this the "unique VRF per RD" condition.
[RFC4364]では、そのRDに関連付けられているすべてのVRFが同じVPNに属している限り、特定のRDを複数のVRFに関連付けることができます。ただし、最も一般的な導入モデルでは、各RDは1つだけのVRFに関連付けられます。 [RFC6513]と[RFC6514]は、この展開モデルを前提としています。つまり、[RFC6513]および[RFC6514]は、すべてのRDが1つだけのVRFに関連付けられていることを前提としています。これを「RDごとの固有のVRF」状態と呼びます。
[RFC6514] defines the MCAST-VPN address family, which has a number of route types. Each Intra-Autonomous System (Intra-AS) "Inclusive Provider Multicast Service Interface" (I-PMSI) A-D route, S-PMSI A-D route, and Source Active A-D route, when exported from a given VRF, contains, in its NLRI, an RD that is associated with the VRF. [RFC6513] and [RFC6514] also discuss a class of routes known as "UMH-eligible" routes; when a UMH-eligible route is exported from a given VRF, its NLRI contains an RD of the VRF.
[RFC6514]は、多数のルートタイプを持つMCAST-VPNアドレスファミリを定義しています。各イントラ自律システム（Intra-AS）の「インクルーシブプロバイダーマルチキャストサービスインターフェイス」（I-PMSI）ADルート、S-PMSI ADルート、およびソースアクティブADルートは、特定のVRFからエクスポートされると、そのNLRIに含まれます。 VRFに関連付けられているRD。 [RFC6513]と[RFC6514]は、「UMH適格」ルートとして知られるクラスのルートについても説明しています。 UMH適格ルートが特定のVRFからエクスポートされる場合、そのNLRIにはVRFのRDが含まれています。
[RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an RD of the VRF from which they are exported: the C-multicast Join routes and the Leaf A-D routes.
[RFC6514]では、NLRIにエクスポート元のVRFのRDが含まれていないMCAST-VPNルートも定義されています。Cマルチキャストの参加ルートとリーフA-Dルートです。
Those route types that, when exported from a given VRF, contain (in their NLRIs) an RD of the VRF, will be known in this document as "local-RD routes".
このドキュメントでは、特定のVRFからエクスポートされたときに（NLRIに）VRFのRDが含まれるルートタイプを「ローカルRDルート」と呼びます。
Given the "unique VRF per RD" condition, if one sees that two local-RD routes have the same RD, one can infer that the two routes originated from the same VRF. This inference can be drawn even if the two routes do not have the same SAFI, as long as the two routes are both local-RD routes.
「RDごとの固有のVRF」条件が与えられた場合、2つのローカルRDルートが同じRDを持っていることがわかると、2つのルートが同じVRFから発信されたと推測できます。この推論は、2つのルートが両方ともローカルRDルートである限り、2つのルートに同じSAFIがなくても描画できます。
This document builds upon [RFC6513] and [RFC6514]; therefore, the "unique VRF per RD" condition is REQUIRED.
このドキュメントは、[RFC6513]と[RFC6514]に基づいています。したがって、「RDごとの固有のVRF」状態が必要です。
[RFC6514] presupposes a further requirement on the use of RDs in the local-RD routes exported from a given VRF. Suppose that a given VRF exports a Source Active A-D route containing (C-S,C-G). That VRF will also export a UMH-eligible route matching C-S. [RFC6514] presupposes that the UMH-eligible route and the Source Active A-D route have the same RD.
[RFC6514]は、特定のVRFからエクスポートされたローカルRDルートでのRDの使用に関するさらなる要件を前提としています。特定のVRFが（C-S、C-G）を含むSource Active A-Dルートをエクスポートするとします。そのVRFは、C-Sに一致するUMH適格ルートもエクスポートします。 [RFC6514]は、UMH適格ルートとソースアクティブA-Dルートが同じRDを持っていることを前提としています。
In most cases, not only is a given RD associated with only a single VRF, but a given VRF is associated with only a single RD. We will call this the "unique RD per VRF" condition. When this condition holds, all the local-RD routes exported from a given VRF will have the same RD. This ensures that the presupposition of the previous paragraph will hold, i.e., that the RD in a Source Active A-D route exported from a given VRF will have the same RD as the corresponding UMH-eligible route exported from the same VRF.
ほとんどの場合、特定のRDは単一のVRFのみに関連付けられているだけでなく、特定のVRFは単一のRDのみに関連付けられています。これを「VRFごとの固有のRD」状態と呼びます。この条件が満たされた場合、特定のVRFからエクスポートされたすべてのローカルRDルートは同じRDを持ちます。これにより、前の段落の前提が維持されます。つまり、特定のVRFからエクスポートされたソースアクティブA-DルートのRDは、同じVRFからエクスポートされた対応するUMH適格ルートと同じRDになります。
Section 7.3 of this document describes a procedure known as "extranet separation". When extranet separation is NOT being used, it is REQUIRED by this document that the "unique RD per VRF" condition hold. This ensures that all the local-RD routes exported from a given VRF will have the same RD.
このドキュメントのセクション7.3では、「エクストラネットの分離」と呼ばれる手順について説明します。エクストラネット分離が使用されていない場合、このドキュメントでは「VRFごとの固有のRD」条件が満たされている必要があります。これにより、特定のVRFからエクスポートされたすべてのローカルRDルートが同じRDを持つことが保証されます。
When extranet separation is used, a VRF that contains both extranet sources and non-extranet sources MUST be configured with two RDs. One of these RDs is known as the "default RD", and the other is known as the "extranet RD". It MUST be known by configuration which RD is the default RD and which is the extranet RD.
エクストラネット分離を使用する場合、エクストラネットソースと非エクストラネットソースの両方を含むVRFは、2つのRDで構成する必要があります。これらのRDの1つは「デフォルトRD」と呼ばれ、もう1つは「エクストラネットRD」と呼ばれます。構成によって、どのRDがデフォルトRDであり、どのRDがエクストラネットRDであるかを認識している必要があります。
When a VRF is configured with only one RD, we will refer to that RD as the "default RD".
VRFが1つのRDのみで構成されている場合、そのRDを「デフォルトRD」と呼びます。
In general, local-RD routes exported from a given VRF will contain the default RD. However, when extranet separation is used, some of the local-RD routes exported from the VRF will contain the extranet RD. Details concerning the exported routes that contain the extranet RD can be found in Sections 4.1 and 7.3.
一般に、特定のVRFからエクスポートされたローカルRDルートには、デフォルトのRDが含まれます。ただし、エクストラネット分離が使用されている場合、VRFからエクスポートされた一部のローカルRDルートにはエクストラネットRDが含まれます。エクストラネットRDを含むエクスポートされたルートに関する詳細は、セクション4.1および7.3に記載されています。
Note that the "unique VRF per RD" condition applies to the extranet RD as well as the default RD. That is, a given extranet RD is associated with a unique VRF.
「RDごとの固有のVRF」条件は、デフォルトのRDだけでなくエクストラネットRDにも適用されることに注意してください。つまり、特定のエクストラネットRDは一意のVRFに関連付けられています。
Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN functionality as specified in [RFC6513] and/or [RFC6514]. In the simplest configuration, VPN-S is a collection of VRFs, each of which is configured with a particular Route Target (RT) value (call it "RT-S") as its import RT and as its export RT. Similarly, VPN-R is a collection of VRFs, each of which is configured with a particular RT value (call it "RT-R") as its import RT and as its export RT.
[RFC6513]や[RFC6514]で指定されているMVPN機能をそれぞれサポートする2つのVPN、VPN-SとVPN-Rについて考えてみましょう。最も単純な構成では、VPN-SはVRFのコレクションであり、それぞれが特定のルートターゲット（RT）値（「RT-S」と呼ばれます）をインポートRTおよびエクスポートRTとして構成されています。同様に、VPN-RはVRFのコレクションであり、それぞれが特定のRT値（「RT-R」と呼ばれます）をインポートRTおよびエクスポートRTとして構成されています。
In this configuration, multicast C-receivers contained in a VPN-R VRF cannot receive multicast data traffic from multicast C-sources contained in a VPN-S VRF. If it is desired to allow this, one needs to create an MVPN "extranet". Creating an extranet requires procedures in addition to those specified in [RFC6513], [RFC6514], and [RFC6625]; this document specifies these additional procedures.
この構成では、VPN-R VRFに含まれるマルチキャストCレシーバーは、VPN-S VRFに含まれるマルチキャストCソースからマルチキャストデータトラフィックを受信できません。これを許可したい場合は、MVPN「エクストラネット」を作成する必要があります。エクストラネットを作成するには、[RFC6513]、[RFC6514]、および[RFC6625]で指定されている手順に加えて、手順が必要です。このドキュメントでは、これらの追加手順について説明します。
In the example above, the additional procedures will allow a selected set of routes exported from the VPN-S VRFs (i.e., from the VRFs containing extranet C-sources) to be imported into the VPN-R VRFs (i.e., into the VRFs containing extranet C-receivers). These routes include the routes that are to be eligible for use as UMH routes (see Section 5.1 of [RFC6513]) in the extranet, as well as a selected set of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, and Source Active A-D routes). Importing these routes into the VPN-R VRFs makes it possible to determine, in the context of a VPN-R VRF, that a particular C-multicast Join needs to be delivered to a particular VPN-S VRF. It also makes it possible to determine, in the context of a VPN-R VRF, the P-tunnel through which the aforementioned VPN-S VRF sends a particular C-flow.
上記の例では、追加の手順により、VPN-S VRFから（つまり、エクストラネットCソースを含むVRFから）エクスポートされた選択されたルートのセットを、VPN-R VRF（つまり、VRFを含む）にインポートできます。エクストラネットCレシーバー）。これらのルートには、エクストラネットでUMHルート（[RFC6513]のセクション5.1を参照）として使用できるルートと、選択されたBGP ADルートのセット（Intra-AS I-PMSI ADルート、S- PMSI ADルート、およびSource Active ADルート）。これらのルートをVPN-R VRFにインポートすると、VPN-R VRFのコンテキストで、特定のC-マルチキャスト結合を特定のVPN-S VRFに配信する必要があると判断できます。また、VPN-R VRFのコンテキストで、前述のVPN-S VRFが特定のCフローを送信するPトンネルを決定することもできます。
Depending on the type of P-tunnel used, it may also be necessary for Leaf A-D routes to be exported by one or more VPN-R VRFs and imported into a VPN-S VRF.
使用されるPトンネルのタイプによっては、Leaf A-Dルートが1つ以上のVPN-R VRFによってエクスポートされ、VPN-S VRFにインポートされる必要がある場合もあります。
There are no extranet-specific procedures governing the use and distribution of BGP C-multicast routes.
BGP Cマルチキャストルートの使用と配信を管理するエクストラネット固有の手順はありません。
If PIM is used as the PE-PE protocol for distributing C-multicast routing information, additional BGP A-D routes must be exported from the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM control messages. Details can be found in Section 6.
C-マルチキャストルーティング情報を配信するためのPE-PEプロトコルとしてPIMが使用されている場合、VPN-S VRFがVPN-S VRFに参加できるように、追加のBGP ADルートをVPN-R VRFからエクスポートしてVPN-S VRFにインポートする必要があります。 VPN-R VRFがPIM制御メッセージの送信に使用するPトンネル。詳細はセクション6をご覧ください。
The simple example above describes an extranet created from two MVPNs, one of which contains extranet C-sources and one of which contains extranet C-receivers. However, the procedures described in this document allow for much more complicated scenarios.
上記の簡単な例では、2つのMVPNから作成されたエクストラネットについて説明しています。1つはエクストラネットCソースを含み、もう1つはエクストラネットCレシーバを含みます。ただし、このドキュメントで説明する手順では、はるかに複雑なシナリオが可能になります。
For instance, an extranet may contain extranet C-sources and/or extranet C-receivers from an arbitrary number of VPNs, not just from two VPNs. An extranet C-receiver in VPN-R may be allowed to receive multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. Similarly, extranet C-sources in VPN-S may be allowed to send multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, VPN-C, etc.
たとえば、エクストラネットには、2つのVPNだけでなく、任意の数のVPNからのエクストラネットCソースやエクストラネットCレシーバーを含めることができます。 VPN-RのエクストラネットCレシーバーは、VPN-A、VPN-B、およびVPN-CのエクストラネットCソースからマルチキャストトラフィックを受信できる場合があります。同様に、VPN-SのエクストラネットCソースは、VPN-A、VPN-B、VPN-CなどにあるマルチキャストCレシーバーにマルチキャストトラフィックを送信できます。
A given VPN customer may desire that only some of its multicast C-sources be treated as extranet C-sources. This can be accomplished by appropriate provisioning of the import and export RTs of that customer's VRFs (as well as the VRFs of other VPNs that contain extranet C-receivers for extranet C-flows of the given customer).
特定のVPNカスタマーは、マルチキャストCソースの一部のみをエクストラネットCソースとして扱うことを希望する場合があります。これは、その顧客のVRF（および特定の顧客のエクストラネットCフロー用のエクストラネットCレシーバーを含む他のVPNのVRF）のインポートおよびエクスポートRTを適切にプロビジョニングすることで実現できます。
A given VPN customer may desire that some of its extranet C-sources can transmit only to a certain set of VPNs while other of its extranet C-sources can transmit only to a different set of VPNs. This can be accomplished by provisioning the VRFs to export different routes with different RTs.
特定のVPN顧客は、エクストラネットCソースの一部は特定のVPNセットにのみ送信でき、他のエクストラネットCソースは別のVPNセットにのみ送信できることを望む場合があります。これは、VRTをプロビジョニングして、異なるRTを持つ異なるルートをエクスポートすることで実現できます。
In all these cases, the VPN customers set the policies, and the Service Provider (SP) implements the policies by the way it provisions the import and export RTs of the VRFs. It is assumed that the customer communicates to the SP the set of extranet C-source addresses and the set of VPNs to which each C-source can transmit. (Recall that every C-source that can transmit to an extranet C-group is an extranet C-source and must be able to transmit to any VPN that has receivers for that group. This must be taken into account when the provisioning is done.) This customer/SP communication is part of the service provisioning process and is outside the scope of this document.
これらすべてのケースで、VPNカスタマーはポリシーを設定し、サービスプロバイダー（SP）はVRFのインポートおよびエクスポートRTをプロビジョニングする方法でポリシーを実装します。顧客がSPにエクストラネットCソースアドレスのセットと各Cソースが送信できるVPNセットを通信すると想定されています。 （エクストラネットCグループに送信できるすべてのCソースはエクストラネットCソースであり、そのグループの受信者を持つすべてのVPNに送信できる必要があることを思い出してください。プロビジョニングが行われるとき、これを考慮に入れる必要があります。 ）この顧客/ SP通信はサービスプロビジョニングプロセスの一部であり、このドキュメントの範囲外です。
It is possible that an extranet C-source will transmit both extranet C-flows and non-extranet C-flows. However, if extranet C-receiver C-R can receive extranet C-flows from extranet C-source C-S, the procedures of this document do not prevent C-R from requesting and receiving the non-extranet flows that are transmitted by C-S. Therefore, allowing an extranet C-source to transmit non-extranet C-flows is NOT RECOMMENDED. However, the SP has no control over the set of C-flows transmitted by a given C-source and can do no more than communicate this recommendation to its customers. (Alternatively, the customer and SP may coordinate on setting up filters to prevent unauthorized flows from being sent to a customer site; such a procedure is outside the scope of this document.) See Section 10 ("Security Considerations") for additional discussion of this issue.
エクストラネットCソースがエクストラネットCフローと非エクストラネットCフローの両方を送信する可能性があります。ただし、エクストラネットCレシーバーC-RがエクストラネットCソースC-SからエクストラネットCフローを受信できる場合、このドキュメントの手順は、C-RがC-Sによって送信される非エクストラネットフローを要求および受信することを妨げません。したがって、エクストラネットCソースが非エクストラネットCフローを送信できるようにすることは推奨されません。ただし、SPは特定のCソースによって送信されるCフローのセットを制御できず、この推奨事項を顧客に伝える以外のことはできません。 （または、お客様とSPは、無許可のフローがお客様のサイトに送信されないようにするためのフィルターの設定について調整する場合があります。このような手順は、このドキュメントの範囲外です。）の詳細については、セクション10（「セキュリティに関する考慮事項」）を参照してください。この問題。
Whenever a VPN is provisioned, there is a risk that errors in provisioning may result in an unintended cross-connection of VPNs. This would create a security problem for the customers. When provisioning an extranet, attention to detail is particularly important, as an extranet intentionally cross-connects VPNs. Care must always be taken to ensure that the cross-connections are according to the policy agreed upon by the SP and its customers.
VPNがプロビジョニングされるときはいつでも、プロビジョニングのエラーにより、意図しないVPNの相互接続が発生する可能性があります。これは、顧客にとってセキュリティ上の問題を引き起こします。エクストラネットはVPNを意図的に相互接続するため、エクストラネットをプロビジョニングするときは、詳細に注意することが特に重要です。クロスコネクトがSPとその顧客によって合意されたポリシーに従っていることを確認するために、常に注意を払う必要があります。
Additionally, if one is connecting two VPNs that have overlapping address spaces, one has to be sure that the inter-VPN traffic neither originates from nor is destined to the part of the address space that is in the overlap. Other problems that can arise due to overlapping address spaces are discussed in Section 2.
さらに、重複するアドレススペースを持つ2つのVPNを接続する場合、VPN間トラフィックが、重複しているアドレススペースの一部から発信されたり、宛先に送信されたりしないことを確認する必要があります。アドレス空間の重複が原因で発生する可能性のある他の問題については、セクション2で説明します。
As specified in [RFC4364], the address space of one VPN may overlap with the address space of another. A given address may be "ambiguous" in that it denotes one system within VPN-A and a different system within VPN-B. In the notation of Section 1.1, if an address C-S is ambiguous between VPN-A and VPN-B, then Host(C-S,A) != Host(C-S,B). However, any given address C-S MUST be unambiguous (i.e., MUST denote a single system) in the context of a given VPN.
[RFC4364]で指定されているように、1つのVPNのアドレス空間が別のVPNのアドレス空間と重複する場合があります。特定のアドレスは、VPN-A内の1つのシステムとVPN-B内の別のシステムを示すという点で「あいまい」である場合があります。セクション1.1の表記では、アドレスC-SがVPN-AとVPN-Bの間であいまいな場合、Host（C-S、A）！= Host（C-S、B）になります。ただし、特定のVPNのコンテキストでは、特定のアドレスC-Sは明確でなければなりません（つまり、単一のシステムを示す必要があります）。
When a set of VRFs belonging to different VPNs are combined into an extranet, it is no longer sufficient for an address to be unambiguous only within the context of a single VPN:
異なるVPNに属する一連のVRFがエクストラネットに結合されると、アドレスが単一のVPNのコンテキスト内でのみ明確であることはもはや十分ではありません。
1. Suppose that C-S is the address of a given extranet C-source contained in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...} containing extranet C-receivers that are allowed by policy to receive extranet C-flows from VPN-A's C-S. The address C-S MUST be unambiguous among this entire set of VPNs {VPN-A, VPN-B, VPN-C, ...}; i.e., Host(C-S,A) == Host(C-S,B) == Host(C-S,C).
1. C-SがVPN-Aに含まれる特定のエクストラネットCソースのアドレスであるとします。次に、VPN-AのC-SからエクストラネットCフローを受信することをポリシーで許可されているエクストラネットCレシーバーを含むVPNのセット{VPN-B、VPN-C、...}について考えます。アドレスC-Sは、このVPNセット全体（VPN-A、VPN-B、VPN-C、...}の間で明確でなければなりません（MUST）。つまり、Host（C-S、A）== Host（C-S、B）== Host（C-S、C）です。
The implication is that C-S in VPN-A is not necessarily an extranet C-source for all VPNs that contain extranet C-receivers; policy MUST be used to ensure that C-S is an extranet C-source for a given VPN, say VPN-B, only if C-S is unambiguous between VPN-A and VPN-B.
つまり、VPN-AのC-Sは、エクストラネットCレシーバーを含むすべてのVPNのエクストラネットCソースであるとは限りません。ポリシーは、C-SがVPN-AとVPN-Bの間で明確である場合にのみ、C-Sが特定のVPN、たとえばVPN-BのエクストラネットCソースであることを確認するために使用する必要があります。
2. If a given VRF contains extranet C-receivers for a given extranet C-source, then the address of this C-source MUST be unambiguous among all the extranet C-sources for which there are C-receivers in the VRF. This is true whether or not C-sources are in VRFs that belong to the same VPN or different VPNs.
2. 特定のVRFに特定のエクストラネットCソースのエクストラネットCレシーバーが含まれている場合、このCソースのアドレスは、VRFにCレシーバーが存在するすべてのエクストラネットCソース間で明確でなければなりません。これは、Cソースが同じVPNまたは異なるVPNに属するVRFにあるかどうかに関係なく当てはまります。
The implication is that if C-S in VRF-X is ambiguous with C-S in VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing C-receivers that are allowed by policy to receive extranet C-flows from both C-S in VRF-X and C-S in VRF-Y.
含意は、VRF-XのCSがVRF-YのCSとあいまいである場合、両方のCSからエクストラネットCフローを受信することをポリシーで許可されているCレシーバーを含むVRF、たとえばVRF-ZがあってはならないことですVRF-XではCS、VRF-YではCS。
Note: A VPN customer may be using anycast addresses. An anycast address is intentionally ambiguous, as it denotes a set of systems rather than a single system. In this document, we will consider an anycast address to be unambiguous in a given context as long as it denotes the same set of systems whenever it occurs in that context.
注：VPNのお客様は、エニーキャストアドレスを使用している可能性があります。エニーキャストアドレスは、単一のシステムではなくシステムのセットを示すため、意図的にあいまいになっています。このドキュメントでは、エニーキャストアドレスは、特定のコンテキストで発生する場合は常に同じシステムのセットを表す限り、特定のコンテキストで明確であると見なします。
A multicast C-group address, say C-G, may also be ambiguous in that it may be used for one multicast group in VPN-A and for an entirely different multicast group in VPN-B. If a set of MVPNs are combined into an extranet and C-G is an extranet C-group, it is necessary to ensure that C-G is unambiguous among the entire set of VPNs whose VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers for that C-group. This may require, as part of the provisioning process, customer/SP communication that is outside the scope of this document.
マルチキャストCグループアドレス（C-Gなど）も、VPN-Aの1つのマルチキャストグループとVPN-Bのまったく異なるマルチキャストグループに使用される可能性があるため、あいまいな場合があります。 MVPNのセットがエクストラネットに結合され、CGがエクストラネットCグループである場合、VRFにエクストラネットCソース、C-RP、および/またはエクストラネットが含まれているVPNのセット全体でCGを明確にする必要があります。そのCグループのCレシーバー。これには、プロビジョニングプロセスの一部として、このドキュメントの範囲外の顧客/ SPコミュニケーションが必要になる場合があります。
Subject to these restrictions, the SP has complete control over the distribution of routes in an MVPN. This control is exerted by provisioning either (1) the export RTs on the VRFs that originate the routes (i.e., the VRFs that contain the extranet C-sources) or (2) the import RTs on the VRFs that receive the routes (i.e., the VRFs that contain the extranet C-receivers), or both.
これらの制限に従い、SPはMVPN内のルートの配布を完全に制御します。この制御は、（1）ルートを発信するVRFのエクスポートRT（つまり、エクストラネットCソースを含むVRF）または（2）ルートを受信するVRFのインポートRT（すなわち、エクストラネットCレシーバーを含むVRF）、またはその両方。
Some of the rules and restrictions on provisioning the RTs are applicable to all extranets; these are specified in Section 4. Sections 6 and 7 list additional rules and restrictions that are applicable only to particular extranet scenarios.
RTのプロビジョニングに関するルールと制限の一部は、すべてのエクストラネットに適用できます。これらはセクション4で指定されています。セクション6と7は、特定のエクストラネットシナリオにのみ適用される追加のルールと制限の一覧です。
Even if all the RTs are provisioned according to the above rules and restrictions, it is still possible for a single P-tunnel to contain multicast data packets whose source and/or group addresses are ambiguous in the context of the set of PEs that receive data from the P-tunnel. That is, the above rules and restrictions are necessary, but not sufficient, to prevent address ambiguity from causing misdelivery of traffic. To prevent such misdelivery, additional procedures or policies must be used.
すべてのRTが上記のルールと制限に従ってプロビジョニングされている場合でも、単一のPトンネルに、データを受信するPEのセットのコンテキストでソースアドレスやグループアドレスが不明確なマルチキャストデータパケットを含めることが可能です。 Pトンネルから。つまり、アドレスのあいまいさがトラフィックの誤配信を引き起こすのを防ぐために、上記のルールと制限は必要ですが、十分ではありません。このような誤配信を防ぐには、追加の手順またはポリシーを使用する必要があります。
Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may carry data packets with ambiguous addresses. The additional procedures and policies needed to prevent misdelivery of data in those scenarios are outlined in Section 2.3. (The detailed procedures described in Sections 6 and 7 incorporate the considerations discussed in Section 2.3.)
セクション2.1および2.2では、特定のPトンネルがあいまいなアドレスを持つデータパケットを伝送する可能性があるシナリオについて説明します。これらのシナリオでデータの誤配信を防ぐために必要な追加の手順とポリシーについては、セクション2.3で概説しています。 （セクション6および7で説明されている詳細な手順には、セクション2.3で説明されている考慮事項が組み込まれています。）
In the following, we will use the notation "VRF A-n" to mean "VRF n of VPN-A".
以下では、「VRF A-n」という表記を使用して「VPN-AのVRF n」を意味します。
If VPN-A and VPN-B have overlapping address spaces and are part of the same extranet, then the following problem may exist, as illustrated in Figure 1.
VPN-AとVPN-Bに重複するアドレススペースがあり、同じエクストラネットの一部である場合、図1に示すように、次の問題が発生する可能性があります。
C-S2(A) C-S1 Join(C-S2(A),G)
\ / /
\ / /
+-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+
|VRF A-1| |---------------------------------| |VRF A-2 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF B-2 |
+-------+---+ P2: (C-S2(B),G) +---+--------+
/ / \
/ / \
C-S2(B) Join(C-S2(B),G) Join(C-S1,G)
Figure 1: Ambiguity of Extranet and Non-extranet Source Address
図1：エクストラネットと非エクストラネットの送信元アドレスのあいまいさ
Suppose that:
仮定：
o C-G is an SSM C-group used in VPN-A and VPN-B.
o C-Gは、VPN-AおよびVPN-Bで使用されるSSM Cグループです。
o VRF A-1, on PE1, contains an extranet C-source, with IP address C-S1, that is allowed to have receivers in VPN-B. VRF A-1 thus exports to VPN-B a UMH-eligible route matching C-S1.
o PE1のVRF A-1には、VPN-Bにレシーバーを置くことが許可されているIPアドレスC-S1のエクストラネットCソースが含まれています。したがって、VRF A-1は、C-S1に一致するUMH適格ルートをVPN-Bにエクスポートします。
o In addition, VRF A-1 contains a non-extranet C-source with IP address C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to other VPN-A VRFs but NOT to VPN-B.
o さらに、VRF A-1には、IPアドレスがC-S2の非エクストラネットCソースが含まれています。 VRF A-1は、C-S2に一致するUMH適格ルートを他のVPN-A VRFにエクスポートしますが、VPN-Bにはエクスポートしません。
o VRF B-1, also on PE1, contains a non-extranet C-source with IP address C-S2. A UMH-eligible route matching C-S2 is thus exported from VRF B-1 to other VRFs in VPN-B.
o VRF B-1もPE1上にあり、IPアドレスがC-S2の非エクストラネットCソースが含まれています。 C-S2に一致するUMH適格なルートは、VRF B-1からVPN-Bの他のVRFにエクスポートされます。
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous address in any extranet that contains both VPN-A VRFs and VPN-B VRFs.
o Host（C-S2、A）！= Host（C-S2、B）。つまり、C-S2は、VPN-A VRFとVPN-B VRFの両方を含むエクストラネットではあいまいなアドレスです。
o VRF B-2, on some other PE, say PE2, requests the multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 matches the route exported from VRF A-1. Thus, B-2's request to receive the (C-S1,C-G) flow is transmitted to VRF A-1.
o VRF B-2は、他のPE、たとえばPE2で、マルチキャストフロー（C-S1、C-G）を要求します。 VRF B-2のコンテキストでは、C-S1はVRF A-1からエクスポートされたルートと一致します。したがって、（C-S1、C-G）フローを受信するB-2の要求は、VRF A-1に送信されます。
o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1は、（C-S1、C-G）トラフィックに対するVRF B-2の要求に応答して、そのトラフィックをPトンネルP1で送信します。
o VRF B-2 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic.
o VRF B-2は、（C-S1、C-G）トラフィックを受信するためにPトンネルP1に参加します。
o VRF A-2, on PE2, requests the (non-extranet) multicast flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the route exported from VRF A-1. Thus, A-2's request to receive the (C-S2,C-G) traffic is transmitted to VRF A-1.
o PE2上のVRF A-2は、（非エクストラネット）マルチキャストフロー（C-S2、C-G）を要求します。 VRF A-2のコンテキストでは、C-S2はVRF A-1からエクスポートされたルートと一致します。したがって、（C-S2、C-G）トラフィックを受信するA-2の要求は、VRF A-1に送信されます。
o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1は、VRF A-2の（C-S2、C-G）トラフィックに対する要求に応答して、そのトラフィックをPトンネルP1に送信します。
o VRF A-2 joins P-tunnel P1 in order to receive the (C-S2,C-G) traffic.
o VRF A-2は、（C-S2、C-G）トラフィックを受信するためにPトンネルP1に参加します。
o VRF B-2 requests the (non-extranet) multicast flow (C-S2,C-G). In the context of VRF B-2, C-S2 matches the route exported from VRF B-1. Thus, B-2's request to receive the (C-S2,C-G) flow is transmitted to VRF B-1.
o VRF B-2は（非エクストラネット）マルチキャストフロー（C-S2、C-G）を要求します。 VRF B-2のコンテキストでは、C-S2はVRF B-1からエクスポートされたルートと一致します。したがって、（C-S2、C-G）フローを受信するB-2の要求は、VRF B-1に送信されます。
o VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P2.
o VRF B-1は、（C-S2、C-G）トラフィックに対するVRF B-2の要求に応答して、そのトラフィックをPトンネルP2に送信します。
o VRF B-2 joins P-tunnel P2.
o VRF B-2がPトンネルP2に参加します。
Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive (C-S2,C-G) traffic on both P-tunnels. The (C-S2,C-G) traffic that VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G) traffic must be forwarded by B-2 to any attached customer sites that have C-receivers for it. But B-2 MUST discard the (C-S2,C-G) traffic that it receives on P1, as this is not the traffic that it has requested. If the (C-S2,C-G) traffic arriving on P1 were forwarded to B-2's customer sites, the C-receivers would not be able to distinguish the two flows, and the result would be a corrupted data stream.
VRF B-2はPトンネルP1とPトンネルP2に参加しているため、両方のPトンネルで（C-S2、C-G）トラフィックを受信します。 VRF B-2が受信する必要がある（C-S2、C-G）トラフィックは、PトンネルP2を移動します。この（C-S2、C-G）トラフィックは、B-2によって、Cレシーバーが接続されている顧客サイトに転送される必要があります。ただし、B-2は、P1で受信した（C-S2、C-G）トラフィックを破棄する必要があります。これは、これが要求したトラフィックではないためです。 P1に到着する（C-S2、C-G）トラフィックがB-2のカスタマーサイトに転送された場合、Cレシーバは2つのフローを区別できず、結果としてデータストリームが破損します。
Note that the procedures of Section 9.1.1 of [RFC6513] ("Discarding Packets from Wrong PE") will not cause VRF B-2 to discard the (C-S2,C-G) traffic that arrives on tunnel P1, because P1 and P2 have the same upstream PE.
[RFC6513]のセクション9.1.1の手順（「間違ったPEからのパケットの破棄」）では、P1とP2が原因で、VRF B-2がトンネルP1に到着した（C-S2、CG）トラフィックを破棄しないことに注意してください同じアップストリームPEがあります。
Therefore, it is necessary to EITHER (1) prevent the above scenario from occurring OR (2) ensure that multicast data packets will be discarded if they arrive on the wrong P-tunnel (even if they arrive from the expected PE). See Section 2.3 for further discussion of this issue.
したがって、（1）上記のシナリオが発生しないようにするか、（2）マルチキャストデータパケットが間違ったPトンネルに到着した場合（予期したPEから到着した場合でも）確実に破棄されるようにする必要があります。この問題の詳細については、セクション2.3を参照してください。
Figure 2 illustrates another example of how overlapping address spaces may cause a problem.
図2は、アドレス空間の重複が問題を引き起こす可能性のある別の例を示しています。
C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G)
\ / /
\ / /
+-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+
|VRF A-1| |---------------------------------| |VRF D-1 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF C-1 |
+-------+---+ P2: (C-S2(B2C),G) +---+--------+
/ / \
/ / \
C-S2(B2C) / \
Join Join
(C-S2(B2C),G) (C-S1(A2C),G)
Figure 2: Ambiguity of Extranet Source Addresses
図2：エクストラネットの送信元アドレスのあいまいさ
Suppose that:
仮定：
o C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C, and VPN-D.
o C-Gは、VPN-A、VPN-B、VPN-C、およびVPN-Dで使用されるSSM Cグループアドレスです。
o VRF A-1, on PE1, contains an extranet C-source, with IP address C-S1, that is allowed by policy to have C-receivers in VPN-C (but not in VPN-D). VRF A-1 thus exports a UMH-eligible route matching C-S1 to VPN-C.
o PE1のVRF A-1には、IPアドレスC-S1のエクストラネットCソースが含まれています。これは、ポリシーによって、VPN-C（VPN-Dではない）にCレシーバーを持つことが許可されています。したがって、VRF A-1は、C-S1に一致するUMH適格ルートをVPN-Cにエクスポートします。
o In addition, VRF A-1 contains an extranet C-source, with IP address C-S2, that is allowed by policy to have C-receivers in VPN-D (but not in VPN-C). VRF A-1 thus exports a UMH-eligible route matching C-S2 to VPN-D.
o さらに、VRF A-1には、IPアドレスC-S2のエクストラネットCソースが含まれています。これは、ポリシーによって、VPN-D（VPN-Cではない）にCレシーバーを持つことが許可されています。したがって、VRF A-1は、C-S2に一致するUMH適格ルートをVPN-Dにエクスポートします。
o VRF B-1, also on PE1, contains an extranet C-source, with IP address C-S2, that is allowed by policy to have C-receivers in VPN-C (but not in VPN-D). VRF B-1 thus exports a UMH-eligible route matching C-S2 to VPN-C.
o VRF B-1もPE1上にあり、IPアドレスC-S2のエクストラネットCソースが含まれています。これにより、ポリシーにより、VPN-CにCレシーバーを持つことが許可されます（VPN-Dにはありません）。したがって、VRF B-1は、C-S2に一致するUMH適格ルートをVPN-Cにエクスポートします。
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous address in any extranet that contains both VPN-A VRFs and VPN-B VRFs.
o Host（C-S2、A）！= Host（C-S2、B）。つまり、C-S2は、VPN-A VRFとVPN-B VRFの両方を含むエクストラネットではあいまいなアドレスです。
o VRF C-1, on some other PE, say PE2, requests the extranet multicast flow (C-S1,C-G). In the context of VRF C-1, C-S1 matches the route exported from VRF A-1. Thus, C-1's request to receive the (C-S1,C-G) flow is transmitted to VRF A-1.
o VRF C-1は、他のPE（PE2など）上で、エクストラネットマルチキャストフロー（C-S1、C-G）を要求します。 VRF C-1のコンテキストでは、C-S1はVRF A-1からエクスポートされたルートと一致します。したがって、（C-S1、C-G）フローを受信するC-1の要求は、VRF A-1に送信されます。
o VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1は、（C-S1、C-G）トラフィックに対するVRF C-1の要求に応答して、そのトラフィックをPトンネルP1に送信します。
o VRF C-1 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic.
o VRF C-1は、（C-S1、C-G）トラフィックを受信するためにPトンネルP1に参加します。
o VRF C-1 requests the extranet multicast flow (C-S2,C-G). In the context of VRF C-1, C-S2 matches the route exported from VRF B-1. Thus, C-1's request to receive the (C-S2,C-G) flow is transmitted to VRF B-1.
o VRF C-1はエクストラネットマルチキャストフロー（C-S2、C-G）を要求します。 VRF C-1のコンテキストでは、C-S2はVRF B-1からエクスポートされたルートと一致します。したがって、（C-S2、C-G）フローを受信するC-1の要求は、VRF B-1に送信されます。
o VRF B-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P2.
o VRF B-1は、（C-S2、C-G）トラフィックをPトンネルP2で送信することによって応答します。
o VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) traffic.
o VRF C-1は、（C-S2、C-G）トラフィックを受信するためにPトンネルP2に参加します。
o VRF D-1, on PE2, requests the extranet multicast flow (C-S2,C-G). In the context of VRF D-1, C-S2 matches the route exported from VRF A-1. Thus, D-1's request to receive the (C-S2,C-G) flow is transmitted to VRF A-1.
o PE2上のVRF D-1は、エクストラネットマルチキャストフロー（C-S2、C-G）を要求します。 VRF D-1のコンテキストでは、C-S2はVRF A-1からエクスポートされたルートと一致します。したがって、（C-S2、C-G）フローを受信するD-1の要求は、VRF A-1に送信されます。
o VRF A-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P1.
o VRF A-1は、（C-S2、C-G）トラフィックをPトンネルP1で送信することによって応答します。
o VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) traffic.
o VRF D-1は、（C-S2、C-G）トラフィックを受信するためにPトンネルP1に参加します。
In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic from VRF A-1, which means that VRF C-1 will also receive the unwanted (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) traffic from VRF B-1; this traffic will be received from P2. Thus, VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both C-flows arrive from the expected PE, PE1.
この例では、VRF A-1は、同じPトンネルP1を使用して、その（C-S2、C-G）トラフィックと（C-S1、C-G）トラフィックの両方を伝送することを選択しています。 VRF C-1は、VRF A-1から（C-S1、C-G）トラフィックを受信するためにトンネルP1に参加しました。つまり、VRF C-1はP1から不要な（C-S2、C-G）トラフィックも受信します。 VRF C-1は、VRF B-1からの（C-S2、C-G）トラフィックも期待しています。このトラフィックはP2から受信されます。したがって、VRF C-1は両方のトンネルで（C-S2、C-G）トラフィックを受信しており、両方のCフローは予期されたPE、PE1から到着します。
Therefore, it is necessary to EITHER (1) prevent the above scenario from occurring OR (2) ensure that VRF C-1 discards any (C-S,C-G) traffic that arrives from the wrong P-tunnel. See Section 2.3 for further discussion of this issue.
したがって、（1）上記のシナリオが発生しないようにするか、（2）VRF C-1が間違ったPトンネルから到着する（C-S、C-G）トラフィックを確実に破棄するようにする必要があります。この問題の詳細については、セクション2.3を参照してください。
Note that the ambiguity described in this section (Section 2.2) would not occur if C-G were an (ASM) extranet C-group. In that case, the scenario would violate the rule, given previously in Section 2, requiring that all sources sending to a particular ASM extranet C-group must have addresses that are unambiguous over all the MVPNs receiving traffic for that C-group.
C-Gが（ASM）エクストラネットCグループである場合、このセクション（セクション2.2）で説明されているあいまいさは発生しないことに注意してください。その場合、シナリオは、セクション2で前述したルールに違反するため、特定のASMエクストラネットCグループに送信するすべてのソースには、そのCグループのトラフィックを受信するすべてのMVPNで明確なアドレスが必要です。
There are two ways to prevent the scenarios discussed in Sections 2.1 and 2.2 from resulting in misdelivery of data; these techniques are discussed in Sections 2.3.1 and 2.3.2, respectively.
セクション2.1と2.2で説明したシナリオがデータの誤配信につながるのを防ぐ方法は2つあります。これらの手法については、それぞれセクション2.3.1および2.3.2で説明します。
Consider a particular C-flow that has receivers in a particular VRF. Sections 6 and 7 describe a set of procedures that enable an egress PE to determine the "expected P-tunnel" for that C-flow in the context of that VRF. If a PE receives packets of the C-flow (as determined by the IP source and/or destination address of the packet), it checks to see if the packet was received on the expected P-tunnel for that VRF. If so, the packet is delivered to the VRF (and thus to the C-flow's receivers in that VRF). If not, the packet is not delivered to the VRF.
特定のVRFにレシーバーがある特定のCフローを考えてみます。セクション6と7では、出力PEがそのVRFのコンテキストでそのCフローの「予想されるPトンネル」を決定できるようにする一連の手順について説明します。 PEがCフローのパケットを受信した場合（パケットのIP送信元アドレスまたは宛先アドレス、あるいはその両方によって決定される）、PEは、そのVRFの予想されるPトンネルでパケットが受信されたかどうかを確認します。その場合、パケットはVRF（したがって、そのVRFのCフローの受信者）に配信されます。そうでない場合、パケットはVRFに配信されません。
Note that at a given egress PE, the wrong P-tunnel for one VRF may be the correct P-tunnel for another.
特定の出力PEでは、あるVRFの間違ったPトンネルが別のVRFの正しいPトンネルである可能性があることに注意してください。
These procedures, if applied at every PE that joins a given P-tunnel, are sufficient to prevent misdelivery of traffic in the scenarios discussed in Sections 2.1 and 2.2.
これらの手順は、特定のPトンネルに参加するすべてのPEに適用される場合、セクション2.1および2.2で説明されているシナリオでのトラフィックの誤配信を防ぐのに十分です。
IF these procedures cannot be applied by every PE that is attached to a given extranet, then the policies of Section 2.3.2 MUST be applied at every VRF containing C-sources for that extranet.
特定のエクストラネットに接続されているすべてのPEでこれらの手順を適用できない場合は、セクション2.3.2のポリシーを、そのエクストラネットのCソースを含むすべてのVRFに適用する必要があります。
In some cases, however, it may be safe to deliver packets that arrive from other than the expected P-tunnel. Suppose that it is known that every packet gets transmitted on only a single P-tunnel. (This will be the case if the "single PMSI per C-flow" transmission model, discussed in Section 3.1, is being used.) Suppose also that it is known that T1 and T2 carry only packets that arrived at the same ingress PE, over one or more VRF interfaces that are associated with the same VRF (i.e., that there is a particular VRF that is the ingress VRF for ALL the packets carried by T1 or T2). In this case, if T1 is the expected P-tunnel for a given (C-S,C-G), it is NOT necessary to discard (S,G) packets that arrive over T2.
ただし、予想されるPトンネル以外から到着したパケットを配信しても安全な場合があります。すべてのパケットが単一のPトンネルでのみ送信されることがわかっているとします。 （これは、セクション3.1で説明した「Cフローごとの単一PMSI」伝送モデルが使用されている場合に当てはまります。）T1とT2が同じ入力PEに到着したパケットのみを運ぶことがわかっているとします。同じVRFに関連付けられている1つ以上のVRFインターフェイスを介して（つまり、T1またはT2によって伝送されるすべてのパケットの入力VRFである特定のVRFがある）。この場合、T1が特定の（C-S、C-G）の予想されるPトンネルである場合、T2経由で到着する（S、G）パケットを破棄する必要はありません。
It is not always possible to determine whether two P-tunnels are carrying packets from the same ingress VRF. However, in some cases, this can be determined by examination of the A-D routes in which the tunnels have been advertised.
2つのPトンネルが同じ入力VRFからのパケットを伝送しているかどうかを判別できるとは限りません。ただし、場合によっては、トンネルがアドバタイズされたA-Dルートを調べることでこれを判別できます。
Consider the following example:
次の例について考えてみます。
o Tunnel T1 is a Point-to-Multipoint (P2MP) multipoint Label Distribution Protocol (mLDP) or RSVP-TE P-tunnel advertised in an Intra-AS I-PMSI A-D route (call it "R1").
o トンネルT1は、ポイントツーマルチポイント（P2MP）マルチポイントラベル配布プロトコル（mLDP）またはRSVP-TE Pトンネルで、AS内I-PMSI A-Dルート（「R1」と呼びます）で通知されます。
o Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an S-PMSI A-D route (call it "R2").
o トンネルT2は、S-PMSI A-Dルート（「R2」と呼びます）でアドバタイズされるP2MP mLDPまたはRSVP-TE Pトンネルです。
o The respective NLRIs of R1 and R2 contain the same RD value.
o R1とR2のそれぞれのNLRIには、同じRD値が含まれています。
o The MPLS Label field of R1's PTA is zero, and the MPLS label value of R2's PTA is zero.
o R1のPTAのMPLSラベルフィールドはゼロであり、R2のPTAのMPLSラベル値はゼロです。
In this example, it can be concluded that T1 and T2 are carrying packets from the same ingress VRF. Thus, if T1 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely delivered to the egress VRF; they do not need to be discarded. Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T1 can be safely delivered to the egress VRF.
この例では、T1とT2が同じ入力VRFからのパケットを伝送していると結論付けることができます。したがって、T1が（C-S、C-G）フローの予想されるPトンネルである場合、T2からの（S、G）パケットは出力VRFに安全に配信できます。廃棄する必要はありません。同様に、T2が（C-S、C-G）フローの予想されるPトンネルである場合、T1からの（S、G）パケットは出力VRFに安全に配信できます。
Another example is the following:
別の例は次のとおりです。
o Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a (C-*,C-*) S-PMSI A-D route (call it "R3").
o トンネルT3は、（C-*、C- *）S-PMSI A-Dルート（「R3」と呼びます）で通知されるP2MP mLDPまたはRSVP-TE Pトンネルです。
o Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a (C-S,C-G) S-PMSI A-D route (call it "R4").
o トンネルT4は、（C-S、C-G）S-PMSI A-Dルート（「R4」と呼びます）でアドバタイズされるP2MP mLDPまたはRSVP-TE Pトンネルです。
o The respective NLRIs of R3 and R4 contain the same RD value.
o R3とR4のそれぞれのNLRIには、同じRD値が含まれています。
o The MPLS Label field of R3's PTA is zero, and the MPLS label value of R4's PTA is zero.
o R3のPTAのMPLSラベルフィールドはゼロであり、R4のPTAのMPLSラベル値はゼロです。
In this example, it can be concluded that T3 and T4 are carrying packets from the same ingress VRF. Thus, if T3 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely delivered to the egress VRF; they do not need to be discarded. Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T3 can be safely delivered to the egress VRF.
この例では、T3とT4が同じ入力VRFからのパケットを伝送していると結論付けることができます。したがって、T3が（C-S、C-G）フローの予想されるPトンネルである場合、T4からの（S、G）パケットは安全に出力VRFに配信できます。廃棄する必要はありません。同様に、T4が（C-S、C-G）フローの予想されるPトンネルである場合、T3からの（S、G）パケットを安全に出力VRFに配信できます。
When Ingress Replication (IR) P-tunnels are being used, please see [MVPN-IR], especially Section 7 ("The PTA's 'MPLS Label' Field") for a discussion of how to determine when packets from other than the expected P-tunnel must be discarded.
Ingress Replication（IR）Pトンネルが使用されている場合、予想されるP以外からのパケットをいつ判別するかについては、[MVPN-IR]、特にセクション7（「PTAの「MPLSラベル」フィールド」）を参照してください。 -tunnelは破棄する必要があります。
For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI contains (C-S,C-G) or (C-S,C-*), the ambiguities described in Sections 2.1 and 2.2 can be prevented by provisioning a policy that assigns, to such P-tunnels, only flows from the same C-source.
NLRIに（CS、CG）または（CS、C- *）が含まれるS-PMSI ADルートでアドバタイズされるPトンネルの場合、セクション2.1および2.2で説明されているあいまいさは、ポリシーにプロビジョニングすることで防止できます。 Pトンネル、同じCソースからのフローのみ。
However, it is not always possible to determine, through inspection of the control messages, whether this policy has been deployed. For instance, suppose that (1) a given VRF has imported a set of S-PMSI A-D routes, (2) each route in the set has bound only a single (C-S1,C-G1) to a single P-tunnel, and (3) each route in the set identifies a different P-tunnel in its PTA than the P-tunnel identified by the PTA of any other route in the set. One cannot infer from this that there is no ambiguity, as the same P-tunnel may also have been advertised in an S-PMSI A-D route that is not imported by the given VRF, and that S-PMSI A-D route may have bound (C-S2,C-G2) to the P-tunnel, where C-S1 != C-S2.
ただし、制御メッセージを調べて、このポリシーが展開されているかどうかを常に判断できるとは限りません。たとえば、（1）特定のVRFがS-PMSI ADルートのセットをインポートしたと仮定します。（2）セット内の各ルートが単一の（C-S1、C-G1）のみを単一のPトンネルにバインドしているとします。 、および（3）セット内の各ルートは、そのPTA内で、セット内の他のルートのPTAによって識別されるPトンネルとは異なるPトンネルを識別します。同じPトンネルが特定のVRFによってインポートされていないS-PMSI ADルートでもアドバタイズされている可能性があり、S-PMSI ADルートがバインドされている可能性があるため、これから曖昧さはないと推測できません（C -S2、C-G2）からPトンネルへ、ここでC-S1！= C-S2。
Therefore, in order to determine that a given P-tunnel (advertised in a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from a single C-source, a PE must have a priori knowledge (through provisioning) that this policy has been deployed. In the remainder of this document, we will refer to this policy as the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this policy is only applicable to P-tunnels that are advertised only in (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes.
したがって、特定のPトンネル（（CS、CG）または（CS、C- *）S-PMSI ADルートでアドバタイズ）が単一のCソースからのCフローのみを伝送することを決定するには、PEはこのポリシーが展開されていることを（プロビジョニングを通じて）事前に知っている。このドキュメントの残りの部分では、このポリシーを「（C-S、C-G）または（C-S、C- *）Pトンネルごとの単一のCソース」ポリシーと呼びます。このポリシーは、（C-S、C-G）または（C-S、C- *）S-PMSI A-DルートでのみアドバタイズされるPトンネルにのみ適用できることに注意してください。
Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always possible for the P-tunnel to contain traffic from multiple C-sources; there is no policy that can prevent that.
もちろん、Pトンネルが（a）I-PMSI ADルート、（b）NLRIに（C-*、C- *）が含まれるS-PMSI ADルート、または（c）S- NLRIに（C-*、CG）が含まれるPMSI ADルートの場合、Pトンネルが複数のCソースからのトラフィックを含むことが常に可能です。それを防ぐことができるポリシーはありません。
However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route contains only traffic addressed to a single C-G, the address uniqueness rules of Section 2 prevent the C-source addresses from being ambiguous; the set of C-sources transmitting to a particular extranet C-group address must be unambiguous over the set of MVPNs that have receivers for that C-group. So, for P-tunnels that are advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described in Sections 2.1 and 2.2 can be prevented by provisioning a policy
ただし、（C-*、C-G）S-PMSI A-DルートでアドバタイズされるPトンネルに単一のC-G宛てのトラフィックのみが含まれる場合、セクション2のアドレス一意性ルールにより、Cソースアドレスがあいまいになるのを防ぎます。特定のエクストラネットCグループアドレスに送信するCソースのセットは、そのCグループのレシーバーを持つMVPNのセットに対して明確でなければなりません。したがって、（C-*、C-G）S-PMSI A-DルートでアドバタイズされるPトンネルの場合、セクション2.1および2.2で説明されているあいまいさは、ポリシーをプロビジョニングすることで防ぐことができます。
that assigns to such P-tunnels only flows to the same extranet C-group. We will refer to this policy as the "single C-group per (C-*,C-G) P-tunnel" policy.
このようなPトンネルに割り当てられるのは、同じエクストラネットCグループにのみ流れる。このポリシーを「（C-*、C-G）Pトンネルごとの単一のCグループ」ポリシーと呼びます。
These considerations can be summarized as follows. IF the procedures referenced in Section 2.3.1 cannot be applied, then the PEs MUST be provisioned so that all of the following conditions hold true for the VRFs that contain extranet C-sources:
これらの考慮事項は、次のように要約できます。セクション2.3.1で参照されている手順を適用できない場合は、エクストラネットCソースを含むVRFに対して次の条件がすべて当てはまるように、PEをプロビジョニングする必要があります。
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is provisioned,
o 「（C-S、C-G）または（C-S、C- *）Pトンネルごとに1つのCソース」ポリシーがプロビジョニングされている
o either no (C-*,C-G) S-PMSI A-D routes are advertised or the "single C-group per (C-*,C-G) P-tunnel" policy is provisioned,
o （C-*、C-G）S-PMSI A-Dルートがアドバタイズされていないか、「（C-*、C-G）Pトンネルごとに1つのCグループ」ポリシーがプロビジョニングされている、
o no P-tunnels are advertised in I-PMSI A-D routes, and
o I-PMSI A-DルートでPトンネルがアドバタイズされていない。
o no (C-*,C-*) S-PMSI A-D routes are advertised.
o （C-*、C- *）S-PMSI A-Dルートはアドバタイズされません。
Section 3 of this document describes a procedure known as "extranet separation". When extranet separation is used, the ambiguity described in Section 2.1 is prevented. However, the ambiguity described in Section 2.2 is not prevented by extranet separation. Therefore, the use of extranet separation is not a sufficient condition for avoiding the use of the procedures discussed in Section 2.3.1. Extranet separation is, however, implied by the policies discussed in this section (Section 2.3.2).
このドキュメントのセクション3では、「エクストラネットの分離」と呼ばれる手順について説明します。エクストラネット分離を使用すると、セクション2.1で説明されているあいまいさが防止されます。ただし、セクション2.2で説明されているあいまいさは、エクストラネットの分離によって防止されません。したがって、エクストラネット分離の使用は、セクション2.3.1で説明されている手順の使用を回避するための十分な条件ではありません。ただし、エクストラネットの分離は、このセクション（セクション2.3.2）で説明するポリシーによって暗示されます。
This document specifies several "extranet transmission" models. A given VRF containing extranet C-sources or C-receivers MUST use only one of these models. Further, if VRF-S contains extranet C-sources, VRF-R contains extranet C-receivers, and it is allowed by policy for an extranet C-receiver in VRF-R to receive a C-flow from an extranet C-source in VRF-S, then VRF-S and VRF-R MUST use the same extranet transmission model. The model used by a given VRF is determined by provisioning.
このドキュメントでは、いくつかの「エクストラネット伝送」モデルを指定しています。エクストラネットCソースまたはCレシーバーを含む特定のVRFは、これらのモデルの1つのみを使用する必要があります。さらに、VRF-SにエクストラネットCソースが含まれている場合、VRF-RにはエクストラネットCレシーバーが含まれ、VRF-RのエクストラネットCレシーバーがエクストラネットCソースからCフローを受信することがポリシーで許可されていますVRF-S、VRF-SおよびVRF-Rは同じエクストラネット伝送モデルを使用する必要があります。特定のVRFで使用されるモデルは、プロビジョニングによって決定されます。
In one extranet transmission model, which we call the "transmitting an extranet C-flow on a single PMSI" model or, more simply, the "single PMSI per C-flow" model, a PE transmitting a packet of an extranet C-flow transmits it on only a single PMSI. If the PMSI is instantiated by a multicast P-tunnel, this means that the PE transmits the packet on a single P-tunnel. Of course, if the PE is a replication point for that multicast P-tunnel, the packet is transmitted more than once by the PE. Similarly, if the PMSI is instantiated by IR, each packet may be transmitted multiple times. It is still the case, though, that the packet is transmitted only on one PMSI.
「単一のPMSIでエクストラネットのCフローを送信する」モデル、より簡単には「Cフローごとの単一のPMSI」モデルと呼ばれる1つのエクストラネット送信モデルでは、エクストラネットCフローのパケットを送信するPE単一のPMSIでのみ送信します。 PMSIがマルチキャストPトンネルによってインスタンス化される場合、これは、PEが単一のPトンネルでパケットを送信することを意味します。もちろん、PEがそのマルチキャストPトンネルの複製ポイントである場合、パケットはPEによって複数回送信されます。同様に、PMSIがIRによってインスタンス化される場合、各パケットは複数回送信される可能性があります。ただし、パケットが1つのPMSIでのみ送信される場合もあります。
This document provides procedures for supporting this transmission model using either BGP or PIM as the PE-PE C-multicast control protocol.
このドキュメントでは、BGPまたはPIMをPE-PE Cマルチキャスト制御プロトコルとして使用して、この伝送モデルをサポートする手順について説明します。
There are two variants of this transmission model: "without extranet separation" and "with extranet separation".
この伝送モデルには、「エクストラネット分離なし」と「エクストラネット分離あり」の2つのバリアントがあります。
In this variant, multicast data traffic from extranet C-sources and from non-extranet C-sources may be carried in the same P-tunnel.
このバリアントでは、エクストラネットCソースと非エクストラネットCソースからのマルチキャストデータトラフィックは、同じPトンネルで伝送されます。
This document provides procedures for supporting this variant using either BGP or PIM as the PE-PE C-multicast control protocol.
このドキュメントでは、BGPまたはPIMをPE-PE Cマルチキャスト制御プロトコルとして使用して、このバリアントをサポートする手順について説明します。
In this variant, multicast data traffic from extranet C-sources and from non-extranet C-sources are never carried in the same P-tunnel. Under certain circumstances, this can reduce the amount of multicast data traffic that is delivered unnecessarily to certain PE routers. It also eliminates the ambiguity discussed in Section 2.1.
このバリアントでは、エクストラネットCソースと非エクストラネットCソースからのマルチキャストデータトラフィックは、同じPトンネルで伝送されません。特定の状況下では、これにより、特定のPEルーターに不必要に配信されるマルチキャストデータトラフィックの量を減らすことができます。また、セクション2.1で説明したあいまいさも解消されます。
By definition, when extranet separation is used, the following rule MUST be applied:
定義により、エクストラネット分離を使用する場合は、次のルールを適用する必要があります。
Traffic from extranet C-sources MUST NOT be carried in the same P-tunnel as traffic from non-extranet C-sources.
エクストラネットCソースからのトラフィックは、非エクストラネットCソースからのトラフィックと同じPトンネルで伝送してはなりません（MUST NOT）。
This rule does not impact those VRFs that contain only non-extranet C-sources, nor does it impact those VRFs that contain only extranet C-sources. However, if a particular VRF contains both kinds of C-sources, it will need to advertise some P-tunnels that are used for carrying only extranet C-flows and some that are used only for carrying non-extranet C-flows.
このルールは、非エクストラネットCソースのみを含むVRFには影響しません。また、エクストラネットCソースのみを含むVRFにも影響しません。ただし、特定のVRFに両方の種類のCソースが含まれている場合、エクストラネットCフローのみの伝送に使用されるPトンネルと、非エクストラネットCフローの伝送のみに使用されるPトンネルをアドバタイズする必要があります。
This document provides procedures for supporting extranet separation when BGP is used as the PE-PE C-multicast control protocol. Support for extranet separation using PIM as the PE-PE C-multicast control protocol is outside the scope of this document.
このドキュメントでは、BGPがPE-PE Cマルチキャスト制御プロトコルとして使用されている場合に、エクストラネット分離をサポートする手順について説明します。 PIMをPE-PE Cマルチキャスト制御プロトコルとして使用するエクストラネット分離のサポートは、このドキュメントの範囲外です。
The second extranet transmission model is called the "transmitting an extranet C-flow over multiple PMSIs" model or, more simply, the "multiple PMSIs per C-flow" model. In this model, a PE may transmit the packets of an extranet C-flow on several different PMSIs.
2番目のエクストラネット送信モデルは、「複数のPMSIを介したエクストラネットCフローの送信」モデル、またはより簡単に言えば、「Cフローごとの複数のPMSI」モデルと呼ばれます。このモデルでは、PEはいくつかの異なるPMSIでエクストラネットCフローのパケットを送信できます。
Support for extranet separation with this model is outside the scope of this document.
このモデルでのエクストラネット分離のサポートは、このドキュメントの範囲外です。
This document provides procedures for supporting this transmission model when PIM is used as the PE-PE C-multicast control protocol. Support for this transmission model when BGP is used as the PE-PE C-multicast control protocol is outside the scope of this document.
このドキュメントでは、PIMがPE-PE Cマルチキャスト制御プロトコルとして使用されている場合に、この伝送モデルをサポートする手順について説明します。 BGPがPE-PE Cマルチキャスト制御プロトコルとして使用されている場合のこの伝送モデルのサポートは、このドキュメントの範囲外です。
As described in Section 5.1 of [RFC6513], in order for a C-flow (C-S,C-G) to be carried across the SP backbone, a VRF that has multicast receivers for that C-flow must import a route that matches C-S, and this route must be "eligible for UMH selection". In this document, we will refer to these routes as "UMH-eligible extranet C-source routes".
[RFC6513]のセクション5.1で説明されているように、C-flow（CS、CG）がSPバックボーンを介して伝送されるためには、そのC-flowのマルチキャストレシーバーを持つVRFが、CSに一致するルートをインポートする必要があります。このルートは「UMH選択の対象」である必要があります。このドキュメントでは、これらのルートを「UMH対応のエクストラネットCソースルート」と呼びます。
The UMH-eligible extranet C-source routes do not necessarily have to be unicast routes; they MAY be SAFI 129 routes (see Section 5.1.1 of [RFC6513]). For example, suppose that one wants a VPN-R C-receiver to be able to receive extranet C-flows from C-sources in VPN-S but does not want any VPN-R system to be able to send unicast traffic to those C-sources. One can achieve this by using SAFI 129 routes as the UMH-eligible routes exported from VPN-S and imported by VPN-R. Since SAFI 129 routes are used only for UMH determination and not for unicast routing, this allows the multicast traffic to be forwarded properly but does not create unicast routes to the C-sources.
UMHに適格なエクストラネットCソースルートは、必ずしもユニキャストルートである必要はありません。それらはSAFI 129ルートである場合があります（[RFC6513]のセクション5.1.1を参照）。たとえば、VPN-R CレシーバーがVPN-SのCソースからエクストラネットCフローを受信できるようにしたいが、VPN-RシステムがそれらのCにユニキャストトラフィックを送信できないようにするとします。 -sources。 VPN-Sからエクスポートされ、VPN-RによってインポートされたUMH適格ルートとしてSAFI 129ルートを使用することにより、これを実現できます。 SAFI 129ルートはUMHの決定にのみ使用され、ユニキャストルーティングには使用されないため、これによりマルチキャストトラフィックを適切に転送できますが、Cソースへのユニキャストルートは作成されません。
If a customer is using PIM-SM in the ASM model and one or more customer sites have C-receivers that are allowed by policy to join a (C-*,C-G) tree, where C-G is an extranet C-group, then any VRF with C-receivers for that group MUST import a UMH-eligible route that matches C-RP, where C-RP is the Rendezvous Point (RP) address for C-G.
顧客がASMモデルでPIM-SMを使用しており、1つ以上の顧客サイトに、ポリシーによって（C-*、CG）ツリーに参加することが許可されているCレシーバーがある場合（CGはエクストラネットCグループ）、そのグループのCレシーバーを持つVRFは、C-RPに一致するUMH適格ルートをインポートする必要があります。C-RPはCGのランデブーポイント（RP）アドレスです。
The UMH-eligible extranet C-source and C-RP routes do not have to be "host routes". That is, they can be routes whose IPv4 address prefixes are not 32 bits in length or whose IPv6 address prefixes are not 128 bits in length. So, it is possible for a UMH-eligible extranet C-source route to match the address of an extranet C-source and to also match the address of a non-extranet C-source. However, if such a route is exported from a VPN-S VRF and imported by a VPN-R VRF, VPN-R receivers will be able to receive C-flows from any non-extranet C-sources whose addresses match that route. To prevent this, the VPN-S VRF SHOULD be provisioned such that it will NOT export a UMH-eligible route that matches (in the context of the VPN-R VRF) both extranet C-sources and non-extranet C-sources. Failure to follow this rule may result in a VPN security violation. (See Section 10.)
UMHに適格なエクストラネットCソースおよびC-RPルートは、「ホストルート」である必要はありません。つまり、IPv4アドレスプレフィックスの長さが32ビットではない、またはIPv6アドレスプレフィックスの長さが128ビットではないルートである可能性があります。したがって、UMH対応のエクストラネットCソースルートがエクストラネットCソースのアドレスと一致し、非エクストラネットCソースのアドレスとも一致する可能性があります。ただし、そのようなルートがVPN-S VRFからエクスポートされ、VPN-R VRFによってインポートされた場合、VPN-Rレシーバーは、アドレスがそのルートに一致する非エクストラネットCソースからCフローを受信できます。これを防ぐには、VPN-S VRFをプロビジョニングして（VPN-R VRFのコンテキストで）エクストラネットCソースと非エクストラネットCソースの両方に一致するUMH適格ルートをエクスポートしないようにする必要があります（SHOULD）。このルールに従わないと、VPNセキュリティ違反が発生する可能性があります。 （セクション10を参照。）
In general, one does not want ALL the routes from the VPN-S VRFs to be exported to all the VPN-R VRFs, as only a subset of the routes in the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route distribution is, as is always the case for a BGP/MPLS IP VPN [RFC4364], controlled by Route Targets (RTs). A variety of route distribution policies can be created by appropriately provisioning the import and export RTs of the various VRFs.
VPN-S VRF内のルートのサブセットのみがUMHに適格なエクストラネットCソースルートになるため、一般に、VPN-S VRFからのすべてのルートがすべてのVPN-R VRFにエクスポートされることは望ましくありません。 。ルート配布は、BGP / MPLS IP VPN [RFC4364]の場合と同様に、ルートターゲット（RT）によって制御されます。さまざまなVRFのインポートおよびエクスポートRTを適切にプロビジョニングすることにより、さまざまなルート配布ポリシーを作成できます。
For example, the VPN-S VRFs that contain extranet C-sources could be configured to apply an export RT whose value is "RT-A-extranet" to the routes that match the extranet C-sources. The VPN-R VRFs that contain extranet C-receivers allowed to receive extranet C-flows from VPN-S extranet C-sources could then be configured with "RT-A-extranet" as an import RT.
たとえば、エクストラネットCソースを含むVPN-S VRFは、値が「RT-A-extranet」であるエクスポートRTをエクストラネットCソースと一致するルートに適用するように構成できます。次に、VPN-SエクストラネットCソースからエクストラネットCフローを受信できるエクストラネットCレシーバーを含むVPN-R VRFは、インポートRTとして「RT-A-エクストラネット」を使用して構成できます。
Arbitrarily complex policies can be created by suitable manipulation of the import and export RTs.
インポートおよびエクスポートRTを適切に操作することにより、任意の複雑なポリシーを作成できます。
If extranet separation is being used and a given VRF is exporting UMH-eligible routes for both extranet C-sources and non-extranet C-sources, then the VRF MUST be configured not only with its default RD but also with an extranet RD. The exported UMH-eligible routes MUST contain the extranet RD in their NLRIs.
エクストラネット分離が使用されており、特定のVRFがエクストラネットCソースと非エクストラネットCソースの両方のUMH適格ルートをエクスポートしている場合、VRFはデフォルトのRDだけでなくエクストラネットRDでも構成する必要があります。エクスポートされたUMH適格ルートには、NLRIにエクストラネットRDが含まれている必要があります。
Consider a C-source, C-S, that may transmit to a particular extranet C-group, C-G.
特定のエクストラネットCグループであるC-Gに送信される可能性があるCソースであるC-Sについて考えます。
In order to follow the procedures of [RFC7761],
[RFC7761]の手順に従うために、
o The "first-hop designated router (DR)" for C-S needs to be able to unicast PIM Register messages to a C-RP that services C-G.
o C-Sの「ファーストホップ指定ルーター（DR）」は、PIM RegisterメッセージをC-Gにサービスを提供するC-RPにユニキャストできる必要があります。
o The C-RPs servicing C-G need to be able to unicast PIM Register-Stop messages to the DR for C-S.
o C-Gにサービスを提供するC-RPは、PIM Register-StopメッセージをC-SのDRにユニキャストできる必要があります。
It follows that if a VRF contains C-S but does not contain a C-RP for C-G, then the VRF MUST import a unicast route matching a C-RP for C-G. Note that the unicast route matching the C-RP is needed whether or not the VRF has also imported a SAFI 129 route matching the C-RP. (If the VRF also contains receivers for C-G and UMH determination is being done using SAFI 129 routes, both a unicast route and a SAFI 129 matching C-RP route are needed.)
したがって、VRFにC-Sが含まれているがC-GのC-RPが含まれていない場合、VRFはC-GのC-RPに一致するユニキャストルートをインポートする必要があります。 VRFがC-RPに一致するSAFI 129ルートもインポートしたかどうかに関係なく、C-RPに一致するユニキャストルートが必要であることに注意してください。 （VRFにC-Gのレシーバーも含まれており、UMH決定がSAFI 129ルートを使用して行われている場合、ユニキャストルートとSAFI 129に一致するC-RPルートの両方が必要です。）
Similarly, if a VRF contains a C-RP for C-G but does not contain C-S, the VRF MUST import a unicast route matching the DR for C-S. Note that the unicast route matching the DR for C-S is needed even if UMH determination is being done using SAFI 129 routes; in that case, if the VRF also contains receivers for C-G, it needs to import a SAFI 129 route matching C-S and a unicast route matching the DR for C-S.
同様に、VRFがC-GのC-RPを含むがC-Sを含まない場合、VRFはC-SのDRと一致するユニキャストルートをインポートする必要があります。 SAFI 129ルートを使用してUMH決定が行われている場合でも、C-SのDRに一致するユニキャストルートが必要であることに注意してください。その場合、VRFにC-Gのレシーバーも含まれている場合、C-Sに一致するSAFI 129ルートと、C-SのDRに一致するユニキャストルートをインポートする必要があります。
If, for a particular extranet C-group, C-G, the customer is using "anycast-RP" [RFC3446] [RFC4610] or the Multicast Source Discovery Protocol (MSDP) [RFC3618], then all the C-RPs serving C-G need to send unicast messages to each other. Thus, any VRF that contains a C-RP for C-G needs to import unicast routes matching ALL the other C-RPs that serve C-G.
特定のエクストラネットCグループのCGについて、お客様が「エニーキャストRP」[RFC3446] [RFC4610]またはマルチキャストソースディスカバリプロトコル（MSDP）[RFC3618]を使用している場合、CGを提供するすべてのC-RPは、ユニキャストメッセージを相互に送信します。したがって、C-GのC-RPを含むすべてのVRFは、C-Gを提供する他のすべてのC-RPと一致するユニキャストルートをインポートする必要があります。
The need to distribute these unicast routes is usually not a problem as long as all the C-sources and C-RPs for C-G are in the same MVPN. If, however, the C-sources are not all in the same MVPN, great care must be taken to ensure that the unicast routes mentioned above are properly distributed.
C-GのすべてのCソースとC-RPが同じMVPNにある限り、これらのユニキャストルートを配布する必要は通常問題になりません。ただし、Cソースがすべて同じMVPN内にない場合は、上記のユニキャストルートが適切に配信されるように十分な注意が必要です。
There may be scenarios in which all the C-sources for C-G are in the same MVPN, but there are receivers in different VPNs, and some or all of the VPNs with receivers have their own C-RPs for C-G. In this case, care must be taken to ensure that the C-RPs can all unicast to each other.
C-GのすべてのCソースが同じMVPNにあるが、異なるVPNにレシーバーがあり、レシーバーを持つ一部またはすべてのVPNにC-Gの独自のC-RPがあるシナリオが存在する場合があります。この場合、C-RPがすべて相互にユニキャストできるように注意する必要があります。
This section imposes a constraint on the way RTs are assigned to (a) UMH-eligible routes and (b) the BGP A-D routes that advertise P-tunnels (i.e., BGP A-D routes that contain a PTA). The constraint specified here applies to any extranet for which the ambiguity described in Section 2.2 is possible. (The conditions under which such ambiguity is possible are also described in Section 2.2.)
このセクションは、RTが（a）UMH適格ルートおよび（b）PトンネルをアドバタイズするBGP A-Dルート（つまり、PTAを含むBGP A-Dルート）に割り当てられる方法に制約を課します。ここで指定された制約は、セクション2.2で説明されている曖昧さが可能であるすべてのエクストラネットに適用されます。 （このようなあいまいさが発生する可能性のある条件については、セクション2.2でも説明しています。）
We want to ensure that, in any given VRF, the UMH-eligible route matching a given extranet C-source has an RT in common with every BGP A-D route that advertises a P-tunnel that may be used to carry extranet multicast traffic from that C-source. We also want to ensure that the UMH-eligible route matching a given extranet C-source does not have any RT in common with any BGP A-D route that advertises a P-tunnel that may be used to carry any multicast traffic from a different C-source that has the same IP address. This enables us to determine whether traffic that appears to be from the given C-source is really arriving on the wrong P-tunnel and hence is really from a different C-source with the same IP address.
特定のVRFで、特定のエクストラネットCソースに一致するUMH適格ルートに、そこからエクストラネットマルチキャストトラフィックを伝送するために使用できるPトンネルをアドバタイズするすべてのBGP ADルートと共通のRTがあることを確認します。 Cソース。また、特定のエクストラネットCソースに一致するUMH適格ルートに、別のCからのマルチキャストトラフィックを伝送するために使用されるPトンネルをアドバタイズするBGP ADルートと共通のRTがないことを確認します。同じIPアドレスを持つソース。これにより、特定のCソースからのように見えるトラフィックが本当に間違ったPトンネルに到達し、したがって同じIPアドレスを持つ別のCソースからのトラフィックであるかどうかを判断できます。
Suppose that an IP address C-S is used in VPN-A as the address of one system and used in VPN-B as the address of a different system. In this case, one or more VPN-A VRFs may export a VPN-IP route whose NLRI is <RD1,S>, and one or more VPN-B VRFs may export a VPN-IP route whose NLRI is <RD2,S>, where RD1 != RD2. Consider two routes -- R1 and R2 -- for which the following conditions all hold:
IPアドレスC-Sが1つのシステムのアドレスとしてVPN-Aで使用され、別のシステムのアドレスとしてVPN-Bで使用されているとします。この場合、1つ以上のVPN-A VRFは、NLRIが<RD1、S>であるVPN-IPルートをエクスポートし、1つ以上のVPN-B VRFは、NLRIが<RD2、S>であるVPN-IPルートをエクスポートします。ここで、RD1！= RD2です。次の条件がすべて当てはまる2つのルート、R1とR2を考えてみます。
o R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or are unicast routes matching a C-RP.
o R1とR2は、UMH対応のエクストラネットCソースまたはC-RPルート、またはC-RPに一致するユニキャストルートです。
o R1 is exported from a VRF of VPN-A, while R2 is exported from a VRF of a different VPN, say VPN-B.
o R1はVPN-AのVRFからエクスポートされ、R2は別のVPN、たとえばVPN-BのVRFからエクスポートされます。
o R1's NLRI specifies IP address prefix S/n.
o R1のNLRIは、IPアドレスプレフィックスS / nを指定します。
o R2's NLRI specifies IP address prefix S/m.
o R2のNLRIは、IPアドレスプレフィックスS / mを指定します。
o m >= n (S/m is either the same as or more specific than S/n).
o m> = n（S / mは、S / nと同じか、より具体的です）。
o There is some host address H such that:
o 次のようなホストアドレスHがあります。
* H denotes a different system in VPN-A than in VPN-B, and
* Hは、VPN-AではVPN-Bとは異なるシステムを示し、
* H/m == S/m (so either S/m or S/n might be a longest match for H in some VRF).
* H / m == S / m（したがって、S / mまたはS / nは、一部のVRFのHで最長の一致になる場合があります）。
We impose the following constraint: RTs MUST be assigned in such a way that R1 and R2 do not have any RT in common.
以下の制約を課します。RTは、R1とR2が共通のRTを持たないように割り当てる必要があります。
(This constraint is not as onerous as it may seem. Typically, R1 and R2 would not have an RT in common, as that might result in their being imported into the same VRF, making the address H ambiguous in that VRF.)
（この制約は見かけほど複雑ではありません。通常、R1とR2にはRTが共通していないため、同じVRFにインポートされて、そのVRFでアドレスHがあいまいになる可能性があります。）
Sections 6 and 7 specify procedures for determining if a received C-flow has been received over the expected P-tunnel. Those procedures will not work if this constraint is violated. (The constraint described in this section is necessary, but not sufficient, for the procedures of Sections 6 and 7 to work; additional constraints that cover the assignment of RTs to BGP A-D routes are given in subsequent sections.)
セクション6および7では、受信したCフローが予想されるPトンネルを介して受信されたかどうかを判断する手順を指定します。この制約に違反すると、これらの手順は機能しません。 （このセクションで説明する制約は、セクション6と7の手順が機能するために必要ですが、十分ではありません。RTのBGP A-Dルートへの割り当てをカバーする追加の制約は、後続のセクションで与えられます。）
Sections 4.1, 4.2, and 4.3 place specific requirements on the way in which certain VPN-IP routes are distributed. In order to ensure that these requirements are met, a VPN customer must tell its SP which routes are the matching routes for extranet C-sources and C-RPs. This may be done as part of the provisioning process. Note that this does not necessarily require customer/provider interaction every time the customer adds a new extranet C-source or C-RP, but only when the IP address of the new C-source or C-RP does not match an existing route that is already being distributed as a VPN-IP extranet route. Nevertheless, it seems worthwhile to support an OPTIONAL mechanism that allows a customer to dynamically mark certain routes as being extranet routes.
セクション4.1、4.2、および4.3では、特定のVPN-IPルートの配布方法に特定の要件を課しています。これらの要件が確実に満たされるようにするために、VPNカスタマーは、エクストラネットCソースとC-RPに一致するルートであるルートをSPに通知する必要があります。これは、プロビジョニングプロセスの一部として行うことができます。これは、顧客が新しいエクストラネットCソースまたはC-RPを追加するたびに顧客/プロバイダーの対話を必ずしも必要としないことに注意してください。ただし、新しいCソースまたはC-RPのIPアドレスが既存のルートと一致しない場合のみはすでにVPN-IPエクストラネットルートとして配布されています。それでも、お客様が特定のルートをエクストラネットルートとして動的にマークできるオプションメカニズムをサポートすることは価値があるようです。
To facilitate this, we define a new Transitive Opaque Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document): the Extranet Source Extended Community. When a Customer Edge (CE) router advertises (via BGP) a route to a PE router and the AFI/SAFI of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source Extended Community MAY be attached to the route. The value field of the Extended Community MUST be set to zero. By placing this Extended Community on a particular route, a CE router indicates to a PE router that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied to that route. That is, the CE router may use this Extended Community to indicate to the PE router that a particular route is to be treated as a route that matches the address of an extranet source and is to be exported accordingly to other VPNs. A PE router that interprets this Extended Community MUST ignore the contents of the value field.
これを容易にするために、新しい推移的な不透明な拡張コミュニティ（[RFC4360]、[RFC7153]、およびこのドキュメントのセクション9を参照）を定義します：エクストラネットソース拡張コミュニティ。カスタマーエッジ（CE）ルーターが（BGPを介して）ルートをPEルーターにアドバタイズし、ルートのAFI / SAFIが1 / 1、1 / 2、1 / 4、2 / 1、2 / 2、または2である場合/ 4、エクストラネットソース拡張コミュニティがルートに接続される場合があります。拡張コミュニティの値フィールドはゼロに設定する必要があります。この拡張コミュニティを特定のルートに配置することにより、CEルーターは、セクション4.1、4.2、および4.3の手順がそのルートに適用されることをPEルーターに示します。つまり、CEルーターはこの拡張コミュニティを使用して、特定のルートがエクストラネットソースのアドレスに一致するルートとして扱われ、他のVPNにエクスポートされることをPEルーターに示すことができます。この拡張コミュニティを解釈するPEルータは、値フィールドの内容を無視する必要があります。
Whether a CE router uses the Extranet Source Extended Community is determined by the configuration of the CE router. If used, the set of routes to which the Extended Community is attached is also determined by configuration of the CE. Note that a particular PE router may or may not support the use of the Extranet Source Extended Community by a particular CE router; this is determined by the service agreement between the SP and its customer.
CEルーターがエクストラネットソース拡張コミュニティを使用するかどうかは、CEルーターの構成によって決まります。使用する場合、拡張コミュニティが接続されるルートのセットも、CEの構成によって決定されます。特定のPEルーターは、特定のCEルーターによるエクストラネットソース拡張コミュニティの使用をサポートする場合とサポートしない場合があります。これは、SPとその顧客の間のサービス契約によって決定されます。
If a CE is advertising SAFI 2 routes to the PE as the UMH-eligible extranet C-source and C-RP routes and the CE is using the Extranet Source Extended Community, it is important that the CE attach that Extended Community to the SAFI 2 routes, rather than just to the corresponding SAFI 1 routes. Otherwise, extranet receivers may not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees.
CEがPEへのSAFI 2ルートをUMH適格エクストラネットCソースおよびC-RPルートとしてアドバタイズし、CEがエクストラネットソース拡張コミュニティを使用している場合、CEはその拡張コミュニティをSAFI 2に接続することが重要です。対応するSAFI 1ルートだけではなく、ルート。そうしないと、エクストラネットレシーバーが（C-S、C-G）または（C-*、C-G）マルチキャストツリーに参加できない場合があります。
However, if the C-sources and the C-RPs for a given extranet C-group are not all in the same VPN, the Extended Community would also have to be attached to the SAFI 1 routes that match the C-RP addresses and to the SAFI 1 routes that match the addresses of the first-hop designated routers for all the C-sources. Otherwise, the first-hop routers might not be able to send PIM Register messages to the C-RPs, and the C-RPs might not be able to send PIM Register-Stop messages to the first-hop routers.
ただし、特定のエクストラネットCグループのCソースとC-RPがすべて同じVPNにない場合は、拡張コミュニティを、C-RPアドレスと一致するSAFI 1ルートに接続し、すべてのCソースの最初のホップ指定ルーターのアドレスと一致するSAFI 1ルート。そうしないと、ファーストホップルーターがPIM RegisterメッセージをC-RPに送信できず、C-RPがPIM Register-Stopメッセージをファーストホップルーターに送信できない場合があります。
While this Extended Community allows a customer to inform the SP dynamically that certain routes are "extranet routes", it does not allow a customer to control the set of RTs that the route will carry when it is redistributed as a VPN-IP route. Thus, it is only useful when all the extranet routes from a given VRF are exported with exactly the same set of RTs. (cf. Section 4.3.1 of [RFC4364], which does provide a mechanism that, if properly supported by the SP, allows the customer to determine the set of RTs carried by a VPN-IP route.) A CE SHOULD NOT attach the Extranet Source Extended Community to any route for which it uses another method of specifying the RTs to be carried by that route. A CE SHOULD NOT attach the Extranet Source Extended Community to a route unless all the extranet routes from the CE's VPN are intended to carry the same set of RTs.
この拡張コミュニティでは、特定のルートが「エクストラネットルート」であることをSPに動的に通知できますが、VPN-IPルートとして再配布されるときにルートが運ぶRTのセットを制御することはできません。したがって、特定のVRFからのすべてのエクストラネットルートがまったく同じRTセットでエクスポートされる場合にのみ役立ちます。 （[RFC4364]のセクション4.3.1を参照してください。これは、SPによって適切にサポートされている場合、お客様がVPN-IPルートによって運ばれるRTのセットを決定できるようにするメカニズムを提供します。）CEは、そのルートが運ぶRTを指定する別の方法を使用するルートへのエクストラネットソース拡張コミュニティ。 CEは、CEのVPNからのすべてのエクストラネットルートが同じRTのセットを伝送するように意図されていない限り、エクストラネットソース拡張コミュニティをルートにアタッチしないでください。
A PE SHOULD ignore the Extranet Source Extended Community if it appears on a route that the CE should not have put it on. A PE that ignores the Extranet Source Extended Community SHOULD NOT follow the procedures of Section 4.4.2.
PEは、CEが配置すべきではないルートにエクストラネットソース拡張コミュニティが存在する場合、それを無視する必要があります。エクストラネットソース拡張コミュニティを無視するPEは、セクション4.4.2の手順に従うべきではありません。
Note that misconfiguration on the CE router can result in the Extranet Source Extended Community being mistakenly attached to a route that is not intended to be exported as an extranet route. This could result in a VPN security violation.
CEルーターの構成が誤っていると、エクストラネットソース拡張コミュニティがエクストラネットルートとしてエクスポートすることを目的としていないルートに誤って接続される可能性があることに注意してください。これにより、VPNセキュリティ違反が発生する可能性があります。
Suppose that a PE receives from a CE a route (call it "R") with the Extranet Source Extended Community. The PE must determine (via the considerations discussed in Section 4.4.1) whether it should ignore that Extended Community on route R; if it should ignore the Extended Community, the procedures described in this section are not followed.
PEがCEからエクストラネットソース拡張コミュニティとのルート（「R」と呼ぶ）を受信するとします。 PEは、（セクション4.4.1で説明した考慮事項を介して）ルートRの拡張コミュニティを無視するかどうかを決定する必要があります。拡張コミュニティを無視する必要がある場合、このセクションで説明されている手順は実行されません。
Otherwise, when the PE originates a VPN-IP route corresponding to route R, the PE MUST attach this Extended Community to that route.
そうでない場合、PEがルートRに対応するVPN-IPルートを発信するとき、PEはこの拡張コミュニティをそのルートにアタッチする必要があります。
A Route Reflector MUST NOT add or remove the Extranet Source Extended Community from the VPN-IP routes reflected by the Route Reflector, including the case where VPN-IP routes received via Internal BGP (IBGP) are reflected to External BGP (EBGP) peers (inter-AS option (c); see Section 10 of [RFC4364]). The value of the Extended Community MUST NOT be changed by the Route Reflector.
ルートリフレクターは、内部BGP（IBGP）を介して受信されたVPN-IPルートが外部BGP（EBGP）ピアに反映される場合を含め、ルートリフレクターによって反映されたVPN-IPルートからエクストラネットソース拡張コミュニティを追加または削除してはなりません（MUST NOT）。 AS間オプション（c）。[RFC4364]のセクション10をご覧ください）。拡張コミュニティの値は、ルートリフレクタによって変更してはなりません。
When re-advertising VPN-IP routes, Autonomous System Border Routers (ASBRs) MUST NOT add/remove the Extranet Source Extended Community from these routes. This includes inter-AS options (b) and (c) (see Section 10 of [RFC4364]). The value of the Extended Community MUST NOT be changed by the ASBRs.
VPN-IPルートを再アドバタイズするとき、自律システム境界ルーター（ASBR）は、これらのルートからエクストラネットソース拡張コミュニティを追加/削除してはなりません（MUST NOT）。これには、AS間オプション（b）および（c）が含まれます（[RFC4364]のセクション10を参照）。拡張コミュニティの値は、ASBRによって変更してはなりません。
When a PE advertises (via BGP) IP routes to a CE, these routes MUST NOT carry the Extranet Source Extended Community unless the PE-CE connection is actually an inter-AS option (a) connection (see Section 10 of [RFC4364]). When the PE-CE connection is not an inter-AS option (a) connection, a CE that receives an IP route with the Extranet Source Extended Community MUST remove it from the route before re-advertising the route.
PEが（BGPを介して）IPルートをCEにアドバタイズする場合、PE-CE接続が実際にAS間のオプション（a）接続でない限り、これらのルートはエクストラネットソース拡張コミュニティを伝送してはなりません（[RFC4364]のセクション10を参照）。 。 PE-CE接続がInter-ASオプション（a）接続でない場合、エクストラネットソース拡張コミュニティでIPルートを受信するCEは、ルートを再アドバタイズする前にルートから削除する必要があります。
The rules for attaching the Extranet Source Extended Community to a VPN-IP route, and the rules for propagating that Extended Community, are needed in order to support the scenario in which a VPN contains an option (a) interconnect (see Section 10 of [RFC4364]). At the option (a) interconnect, the VPN-IP route gets translated back to an IP route, and the RTs are stripped off before the IP route is propagated. If the Extranet Source Extended Community has also been stripped off, there is no way for the router at the other end of the option (a) interconnect to know that the route represents an extranet source. Thus, the technique of using the Extranet Source Extended Community to dynamically signal that a particular route represents an extranet source will not work correctly across an option (a) interconnect unless the rules in this section are followed.
VPNにオプション（a）相互接続が含まれているシナリオをサポートするには、エクストラネットソース拡張コミュニティをVPN-IPルートに接続するためのルール、およびその拡張コミュニティを伝播するためのルールが必要です（[ RFC4364]）。オプション（a）の相互接続では、VPN-IPルートがIPルートに変換され、IPルートが伝達される前にRTが取り除かれます。エクストラネットソース拡張コミュニティも取り除かれている場合、オプション（a）の相互接続の反対側にあるルーターが、ルートがエクストラネットソースを表していることを知る方法はありません。したがって、エクストラネットソース拡張コミュニティを使用して、特定のルートがエクストラネットソースを表すことを動的に通知する手法は、このセクションのルールに従わない限り、オプション（a）相互接続では正しく機能しません。
We define a new Transitive Opaque Extended Community: the Extranet Separation Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document). This Extended Community is used only when extranet separation is being used. Its value field MUST be set to zero upon origination, MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers. A Route Reflector MUST NOT add or remove the Extranet Separation Extended Community from the routes it reflects, including the case where routes received via IBGP are reflected to EBGP peers (inter-AS option (c); see Section 10 of [RFC4364]).
新しい推移的な不透明な拡張コミュニティであるエクストラネット分離拡張コミュニティを定義します（このドキュメントの[RFC4360]、[RFC7153]、およびセクション9を参照）。この拡張コミュニティは、エクストラネット分離が使用されている場合にのみ使用されます。その値フィールドは、発信時にゼロに設定する必要があり、受信時に無視する必要があり、中間ルーターによって変更せずに渡す必要があります。ルートリフレクターは、IBGP経由で受信したルートがEBGPピアに反映される場合（AS間オプション（c）、[RFC4364]のセクション10を参照）を含め、エクストラネット分離拡張コミュニティを反映するルートに追加または削除してはなりません（MUST NOT）。
If a VRF has been provisioned to use extranet separation and that VRF has been provisioned to transmit any extranet C-flows on a P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, then any UMH-eligible routes that are exported from that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST carry the Extranet Separation Extended Community. In addition, if an I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route exported from that VRF is used to carry extranet traffic, that A-D route MUST also carry the Extranet Separation Extended Community. Further details may be found in Sections 7.3, 7.4.4, and 7.4.5.
エクストラネット分離を使用するようにVRFがプロビジョニングされ、そのVRFがI-PMSI ADルートまたは（C-*、C- *）SでアドバタイズするPトンネルでエクストラネットCフローを送信するようにプロビジョニングされている場合-PMSI ADルート、およびセクション4.1、4.2、4.3の手順に従ってVRFからエクスポートされるUMH適格ルートは、エクストラネット分離拡張コミュニティを伝送する必要があります。さらに、そのVRFからエクスポートされたI-PMSI A-Dルートまたは（C-*、C- *）S-PMSI A-Dルートがエクストラネットトラフィックの伝送に使用される場合、そのA-Dルートはエクストラネット分離拡張コミュニティも伝送する必要があります。詳細については、セクション7.3、7.4.4、および7.4.5を参照してください。
Except where otherwise specified, this section describes procedures and restrictions that are independent of the PE-PE C-multicast control protocol.
特に明記されていない限り、このセクションでは、PE-PE Cマルチキャスト制御プロトコルに依存しない手順と制限について説明します。
Suppose that there is an extranet C-flow such that:
次のようなエクストラネットCフローがあるとします。
o The extranet C-source of that C-flow is in VRF A-1.
o そのCフローのエクストラネットCソースはVRF A-1にあります。
o One or more extranet C-receivers of that C-flow are in VRF B-1.
o そのCフローの1つ以上のエクストラネットCレシーバーがVRF B-1にあります。
In this case, VRF A-1 MUST export a UMH-eligible route that matches the extranet C-source address, and VRF B-1 MUST import that route. In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an S-PMSI A-D route specifying the P-tunnel through which it will send the data traffic of the given extranet C-flow, and VRF B-1 MUST import that route. If BGP is the PE-PE C-multicast control protocol, then under certain conditions (as specified in [RFC6514]), VRF A-1 may also need to export a Source Active A-D route specifying that it contains a source of the given C-flow, and VRF B-1 must import that Source Active A-D route. That is, in order for VRF B-1 to receive a C-flow from a given extranet C-source contained in VRF A-1, VRF A-1 MUST export a set of A-D routes that are "about" that source, and VRF B-1 MUST import them.
この場合、VRF A-1はエクストラネットCソースアドレスと一致するUMH適格ルートをエクスポートする必要があり、VRF B-1はそのルートをインポートする必要があります。さらに、VRF A-1は、イントラAS I-PMSI ADルートまたはS-PMSI ADルートをエクスポートする必要があります。これは、特定のエクストラネットCフローのデータトラフィックを送信するPトンネル、およびVRF B-を指定します。 1そのルートをインポートする必要があります。 BGPがPE-PE Cマルチキャスト制御プロトコルである場合、特定の条件下（[RFC6514]で指定）で、VRF A-1は、特定のCのソースが含まれていることを指定して、ソースアクティブADルートをエクスポートする必要がある場合もあります。 -flow、およびVRF B-1はそのソースアクティブADルートをインポートする必要があります。つまり、VRF B-1がVRF A-1に含まれる特定のエクストラネットCソースからCフローを受信するためには、VRF A-1はそのソースに「約」いるADルートのセットをエクスポートする必要があります。 VRF B-1はそれらをインポートする必要があります。
One way to ensure this is to provision an RT that is carried by all the routes exported from VRF A-1 that are "about" a given extranet C-source and also provision this RT as an import RT at any VRF (such as VRF B-1) that is allowed to receive extranet flows from that source.
これを確実にする1つの方法は、VRF A-1からエクスポートされたすべてのルートによって運ばれるRTを特定のエクストラネットCソースについて「提供」し、このRTを任意のVRF（VRFなど）でインポートRTとしてプロビジョニングすることですB-1）そのソースからエクストラネットフローを受信することが許可されている。
If the "single PMSI per C-flow" transmission model is being used (with or without extranet separation), there is an additional requirement, stated below, regarding the way RTs are provisioned, as the RTs carried by a UMH-eligible route that matches a given extranet C-source may need to be used to identify the A-D routes that are "about" that source.
「Cフローごとの単一PMSI」伝送モデルが使用されている場合（エクストラネット分離の有無にかかわらず）、RTのプロビジョニング方法に関して、以下に示す追加の要件があります。特定のエクストラネットに一致Cソースは、そのソースの「約」であるADルートを識別するために使用する必要がある場合があります。
Consider the following scenario:
次のシナリオを検討してください。
o IP address S is the address of one system in VPN-A and the address of a different system in VPN-B.
o IPアドレスSは、VPN-Aの1つのシステムのアドレスであり、VPN-Bの別のシステムのアドレスです。
o VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching route for S.
o PE1のVRF A-1は、Sに一致するルートであるUMH適格ルートR1をエクスポートします。
o VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a P-tunnel through which VRF A-1 may send traffic whose C-source is S, where one of the following conditions holds:
o PE1のVRF A-1は、A-DルートP1をエクスポートします。このPTAは、VRF A-1がC送信元がSであるトラフィックを送信するPトンネルを識別します。次のいずれかの条件が成立します。
* P1 is an I-PMSI A-D route, OR
* P1はI-PMSI A-Dルート、または
* P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or (C-*,C-G), OR
* P1はS-PMSI A-Dルートで、NLRIに（C-*、C- *）または（C-*、C-G）が含まれている、または
* P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is not provisioned, OR
* P1は、NLRIに（CS、CG）または（CS、C- *）を含むS-PMSI ADルートですが、「（CS、CG）または（CS、C- *）Pトンネルごとの単一のCソース」ポリシーがプロビジョニングされていない、または
* P1 is a Source Active A-D route whose NLRI contains (C-S,C-G).
* P1は、NLRIに（C-S、C-G）が含まれるソースアクティブA-Dルートです。
o VRF B-1 on PE1 exports a UMH-eligible route R2, which is a matching route for S.
o PE1のVRF B-1は、Sに一致するルートであるUMH適格ルートR2をエクスポートします。
o VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a P-tunnel on which VRF B-1 may send traffic whose C-source is S, where one of the following conditions holds:
o PE1のVRF B-1は、A-DルートP2をエクスポートします。このPTAは、VRF B-1がCソースがSであるトラフィックを送信するPトンネルを識別します。ここで、次のいずれかの条件が成立します。
* P2 is an I-PMSI A-D route, OR
* P2はI-PMSI A-Dルート、または
* P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or (C-*,C-G), OR
* P2は、NLRIが（C-*、C- *）または（C-*、C-G）を指定するS-PMSI A-Dルートである、または
* P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is not provisioned, OR
* P2は、NLRIが（CS、CG）または（CS、C- *）を指定するS-PMSI ADですが、「（CS、CG）または（CS、C- *）Pトンネルごとの単一のCソース」ポリシープロビジョニングされていない、または
* P2 is a Source Active A-D route whose NLRI contains (C-S,C-G).
* P2は、NLRIに（C-S、C-G）が含まれるソースアクティブA-Dルートです。
As implied by the rules of Section 4.1, there MUST NOT be any RT that is common to both R1 and R2. In addition, the following set of rules for RT assignment MUST be followed when extranets are supported. These rules support all the extranet transmission models described in this specification:
セクション4.1のルールで暗示されているように、R1とR2の両方に共通するRTがあってはなりません。さらに、エクストラネットがサポートされている場合、RT割り当てに関する次のルールセットに従う必要があります。これらのルールは、この仕様で説明されているすべてのエクストラネット転送モデルをサポートしています。
o There MUST NOT be any RT that is carried by both P1 and P2.
o P1とP2の両方で運ばれるRTがあってはなりません。
o The intersection of the set of RTs carried by P1 and the set of RTs carried by R1 MUST be non-null, and any VRF that imports both P1 and R1 MUST be configured with an import RT from this intersection.
o P1によって伝送されるRTのセットとR1によって伝送されるRTのセットの交差は非ヌルでなければならず、P1とR1の両方をインポートするすべてのVRFは、この交差からのインポートRTで設定する必要があります。
o The intersection of the set of RTs carried by P2 and the set of RTs carried by R2 MUST be non-null, and any VRF that imports both P2 and R2 MUST be configured with an import RT from this intersection.
o P2によって伝送されるRTのセットとR2によって伝送されるRTのセットの交差は非ヌルでなければならず、P2とR2の両方をインポートするすべてのVRFはこの交差からのインポートRTで設定する必要があります。
Suppose that VRF C-1 on PE2 imports P1 and R1 from VRF A-1 while also importing P2 from VRF B-1. Since
PE2のVRF C-1がVRF A-1からP1とR1をインポートし、同時にVRF B-1からP2をインポートするとします。以来
o R1 is VRF C-1's route to S,
o R1はSへのVRF C-1のルートです。
o R1 has an RT in common with P1, and
o R1にはP1と共通のRTがあり、
o R1 has no RT in common with P2,
o R1にはP2と共通のRTがありません。
it can be concluded that VRF C-1 should expect that multicast traffic from S will arrive on the P-tunnel specified in P1. See Sections 6 and 7 for more details on determining the expected P-tunnel for a given extranet C-flow.
VRF C-1は、SからのマルチキャストトラフィックがP1で指定されたPトンネルに到着することを期待する必要があると結論付けることができます。特定のエクストラネットCフローで予想されるPトンネルを決定する方法の詳細については、セクション6および7を参照してください。
While the assignment of import and export RTs to routes is a deployment and provisioning issue rather than a protocol issue, it should be understood that failure to follow these rules is likely to result in VPN security violations.
インポートとエクスポートのRTのルートへの割り当ては、プロトコルの問題ではなく、展開とプロビジョニングの問題ですが、これらのルールに従わないと、VPNセキュリティ違反が発生する可能性があることを理解してください。
An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree"; see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries all the multicast traffic of a given MVPN that enters the backbone network via a particular PE. An Inclusive Tunnel is advertised in the PTA of an I-PMSI A-D route.
インクルーシブトンネル（「インクルーシブツリー」と呼ばれることもあります。[RFC6513]のセクション2.1.1を参照）は、デフォルトで、特定のPEを介してバックボーンネットワークに入る特定のMVPNのすべてのマルチキャストトラフィックを運ぶトンネルです。包含トンネルは、I-PMSI A-DルートのPTAでアドバタイズされます。
This section applies when Inclusive Tunnels are created using either RSVP-TE P2MP or IR.
このセクションは、RSVP-TE P2MPまたはIRを使用してインクルーシブトンネルが作成される場合に適用されます。
Suppose that a VRF, say VRF-S, contains a given extranet C-source C-S, and VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP RSVP-TE P-tunnel or an IR P-tunnel to carry extranet traffic.
VRF、たとえばVRF-Sに特定のエクストラネットCソースCSが含まれ、VRF-SがそのイントラAS I-PMSI ADルートでP2MP RSVP-TE PトンネルまたはIR Pトンネルのいずれかをアドバタイズするとします。エクストラネットトラフィックを伝送します。
In order for VRF-S to set up the P2MP RSVP-TE or IR P-tunnel, it must know all the PEs that are leaf nodes of the P-tunnel, and to learn this it must import an Intra-AS I-PMSI A-D route from every VRF that needs to receive data through that tunnel.
VRF-SがP2MP RSVP-TEまたはIR Pトンネルをセットアップするには、PトンネルのリーフノードであるすべてのPEを認識している必要があり、これを学習するには、AS内I-PMSIをインポートする必要があります。そのトンネルを介してデータを受信する必要があるすべてのVRFからのADルート。
Therefore, if VRF-R contains an extranet C-receiver that is allowed by policy to receive extranet flows from C-S, the RT(s) carried by the Intra-AS I-PMSI A-D routes originated by VRF-R MUST be such that those Intra-AS I-PMSI A-D routes will be imported into VRF-S.
したがって、VRF-Rに、CSからエクストラネットフローを受信することをポリシーで許可されているエクストラネットCレシーバーが含まれている場合、VRF-Rによって開始されたイントラAS I-PMSI ADルートによって運ばれるRTは、 Intra-AS I-PMSI ADルートはVRF-Sにインポートされます。
In the case of IR, this has the following consequence: if an egress PE has n VRFs with receivers for a flow that VRF-S transmits on its I-PMSI, that egress PE will receive n copies of the same packet, one for each of the n VRFs.
IRの場合、これは次の結果をもたらします。出力PEに、VRF-SがI-PMSIで送信するフローのレシーバーを持つVRFがn個ある場合、その出力PEは同じパケットのコピーをそれぞれ1つずつ受信しますn VRFの。
Note that Section 9.1.1 of [RFC6514] prohibits the "Leaf Information Required" flag from being set in the PTA of an Intra-AS I-PMSI A-D route. If this prohibition is ever removed, the requirement of this section will apply only if VRF-S does not set that flag.
[RFC6514]のセクション9.1.1は、「Leaf Information Required」フラグがIntra-AS I-PMSI A-DルートのPTAに設定されることを禁止していることに注意してください。この禁止事項が取り除かれた場合、このセクションの要件は、VRF-Sがそのフラグを設定しない場合にのみ適用されます。
This section applies only when Inclusive Tunnels are created via IR.
このセクションは、包括的トンネルがIRを介して作成される場合にのみ適用されます。
[RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be instantiated by IR. The concept of an IR P-tunnel, and the procedures for supporting IR P-tunnels, are explained more fully in [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree in which a packet is transmitted from one node on the tree to another by being encapsulated and sent through a unicast tunnel.
[RFC6513]と[RFC6514]は、IRによってI-PMSIをインスタンス化できるようにする手順を指定しています。 IR Pトンネルの概念とIR Pトンネルをサポートするための手順については、[MVPN-IR]で詳しく説明しています。 IR Pトンネルは、パケットがカプセル化されてユニキャストトンネルを介して送信されることにより、ツリー上のノードから別のノードにパケットが送信されるP2MPツリーと考えることができます。
As discussed in Section 2, when I-PMSIs are used to support extranets, egress PEs MUST have the ability to discard customer multicast data packets that arrive on the wrong P-tunnel. When I-PMSIs are instantiated by IR, this implies that the following two procedures MUST be followed:
セクション2で説明したように、エクストラネットをサポートするためにI-PMSIが使用される場合、出力PEは、間違ったPトンネルに到着する顧客のマルチキャストデータパケットを破棄する機能を持っている必要があります。 I-PMSIがIRによってインスタンス化される場合、これは次の2つの手順に従う必要があることを意味します。
1. One of the following three procedures MUST be followed:
1. 次の3つの手順のいずれかに従う必要があります。
a. the "Single Forwarder Selection" procedures of Section 9.1.2 of [RFC6513]
a. [RFC6513]のセクション9.1.2の「シングルフォワーダーの選択」手順
b. the "native PIM methods" of Section 9.1.3 of [RFC6513]
b. [RFC6513]のセクション9.1.3の「ネイティブPIMメソッド」
c. the unicast encapsulation used to transmit packets along the IR P-tunnel is such as to enable the receiving node to identify the transmitting node (note that this would not be the case if, for example, the unicast tunnels were MP2P LSPs)
c. IR Pトンネルに沿ってパケットを送信するために使用されるユニキャストカプセル化は、受信ノードが送信ノードを識別できるようにするためのものです（たとえば、ユニキャストトンネルがMP2P LSPの場合はこれに該当しません）。
and
そして
2. If a PE assigns an MPLS label value in the PTA of an Intra-AS or Inter-AS I-PMSI A-D route that it originates, that label value MUST NOT appear in the PTA of any other I-PMSI or S-PMSI A-D route originated by the same PE.
2. PEが発信元のIntra-ASまたはInter-AS I-PMSI ADルートのPTAでMPLSラベル値を割り当てる場合、そのラベル値は他のI-PMSIまたはS-PMSI ADルートのPTAに表示してはなりません（MUST NOT）同じPEから発信されました。
Failure to follow these procedures would make it impossible to discard packets that arrive on the wrong P-tunnel and thus could lead to duplication of data.
これらの手順に従わないと、間違ったPトンネルに到着したパケットを破棄できなくなり、データの重複につながる可能性があります。
If it is desired to support extranets while also using IR to instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs instead of I-PMSIs. (See [RFC6625], as well as Sections 7.2.2, 7.3.2, and 7.4.4 of this document.) This has much the same effect in the data plane, and there are no restrictions on the type of unicast tunnel that can be used for instantiating S-PMSIs.
IRを使用してPMSIをインスタンス化しながらエクストラネットをサポートする必要がある場合は、I-PMSIの代わりに（C-*、C- *）S-PMSIを使用することもできます。 （[RFC6625]、およびこのドキュメントのセクション7.2.2、7.3.2、7.4.4を参照してください。）これは、データプレーンでもほとんど同じ効果があり、ユニキャストトンネルのタイプに制限はありません。 S-PMSIのインスタンス化に使用できます。
Section 6.4.5 of [RFC6513] describes a way to support VPNs using I-PMSIs that are instantiated by IR, using no S-PMSIs, but using "explicit tracking" to ensure that a C-flow goes only to egress PEs that have receivers for it. This document does not provide procedures to support extranets using that model.
[RFC6513]のセクション6.4.5は、IRによってインスタンス化されたI-PMSIを使用し、S-PMSIを使用せずに、「明示的な追跡」を使用して、Cフローがそれのための受信機。このドキュメントでは、そのモデルを使用するエクストラネットをサポートする手順については説明していません。
As specified in [RFC6513], when PIM is used as the PE-PE C-multicast control plane for a particular MVPN, there is a "Multidirectional Inclusive Provider Multicast Service Interface" (MI-PMSI) for that MVPN, and all the PEs of that MVPN must be able to send and receive on that MI-PMSI. Associated with each VRF of the MVPN is a PIM C-instance, and the PIM C-instance treats the MI-PMSI as if it were a LAN interface. That is, the "ordinary" PIM procedures run over the MI-PMSI just as they would over a real LAN interface, except that the data-plane and control-plane "Reverse Path Forwarding (RPF) checks" need to be modified. Section 5.2 of [RFC6513] specifies the RPF check modifications for non-extranet MVPN service.
[RFC6513]で指定されているように、PIMが特定のMVPNのPE-PE Cマルチキャストコントロールプレーンとして使用される場合、そのMVPNとすべてのPEに「Multidirectional Inclusive Provider Multicast Service Interface」（MI-PMSI）があります。そのMVPNは、そのMI-PMSIで送受信できる必要があります。 MVPNの各VRFにはPIM Cインスタンスが関連付けられており、PIM CインスタンスはMI-PMSIをLANインターフェイスのように扱います。つまり、「通常の」PIMプロシージャは、データプレーンとコントロールプレーンの「Reverse Path Forwarding（RPF）チェック」を変更する必要があることを除いて、実際のLANインターフェイスを介して実行するのと同じようにMI-PMSIを介して実行されます。 [RFC6513]のセクション5.2は、非エクストラネットMVPNサービスのRPFチェックの変更を指定しています。
For example, suppose that there are two VPNs: VPN-S and VPN-R. In the absence of extranet support, all the VRFs of VPN-S are connected via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to provide extranet service in which the extranet C-sources are attached to some set of VPN-S VRFs while the extranet C-receivers are attached to some set of VPN-R VRFs, then we have two choices:
たとえば、VPN-SとVPN-Rの2つのVPNがあるとします。エクストラネットサポートがない場合、VPN-SのすべてのVRFは1つのMI-PMSI（「VPN-S MI-PMSI」と呼ぶ）を介して接続され、VPN-RのすべてのVRFは別の（「 VPN-R MI-PMSI」）。エクストラネットCソースがVPN-S VRFの一部のセットに接続され、エクストラネットCレシーバーがVPN-R VRFの一部のセットに接続されるエクストラネットサービスを提供する場合、2つの選択肢があります。
1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or
1. VPN-R VRFがVPN-S MI-PMSIに参加する必要がある、または
2. the VPN-S VRFs need to join the VPN-R MI-PMSI.
2. VPN-S VRFは、VPN-R MI-PMSIに参加する必要があります。
The first choice is used to support the "single PMSI per C-flow" transmission model. The second choice is used to support the "multiple PMSIs per C-flow" transmission model.
最初の選択は、「Cフローごとの単一PMSI」伝送モデルをサポートするために使用されます。 2番目の選択肢は、「Cフローごとの複数のPMSI」伝送モデルをサポートするために使用されます。
Procedures for both models are described below.
両方のモデルの手順を以下に示します。
To support these models, it must be possible to determine which I-PMSI A-D routes are associated with the VPN-S I-PMSI and which I-PMSI A-D routes are associated with the VPN-R I-PMSI. Procedures are given for assigning RTs to these routes in a way that makes this determination possible.
これらのモデルをサポートするには、VPN-S I-PMSIに関連付けられているI-PMSI A-Dルートと、VPN-R I-PMSIに関連付けられているI-PMSI A-Dルートを判別できる必要があります。この決定を可能にする方法でこれらのルートにRTを割り当てる手順が示されています。
Both models allow the use of S-PMSIs to carry multicast data traffic. If a VRF containing receivers can receive from multiple MI-PMSIs, each S-PMSI must be uniquely associated with a particular MI-PMSI. Procedures are given for assigning RTs to these routes in a way that makes this determination possible.
どちらのモデルでも、S-PMSIを使用してマルチキャストデータトラフィックを伝送できます。 VRFを含むレシーバーが複数のMI-PMSIから受信できる場合、各S-PMSIは特定のMI-PMSIに一意に関連付けられている必要があります。この決定を可能にする方法でこれらのルートにRTを割り当てる手順が示されています。
All the procedures specified in Sections 3, 4, and 5 still apply.
セクション3、4、および5で指定されたすべての手順が引き続き適用されます。
Note that there are no special extranet procedures for Inter-AS I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes are not used when PIM is the PE-PE C-multicast protocol.
Inter-AS I-PMSI A-DルートまたはLeaf A-Dルートには、特別なエクストラネット手順はないことに注意してください。 PIMがPE-PE Cマルチキャストプロトコルである場合、ソースアクティブA-Dルートは使用されません。
In the absence of extranet service, suppose that each VRF of a given VPN (call it "VPN-S") is configured with RT-S as its import and export RT, and that each VRF of a second VPN (call it "VPN-R") is configured with RT-R as its import and export RT. We will refer to RT-S and RT-R as "non-extranet RTs".
エクストラネットサービスがない場合、特定のVPN（「VPN-S」と呼ぶ）の各VRFがインポートおよびエクスポートRTとしてRT-Sで構成され、2番目のVPN（「VPN」と呼ぶ）の各VRFが構成されているとします。 -R "）は、インポートおよびエクスポートRTとしてRT-Rで構成されます。 RT-SおよびRT-Rを「非エクストラネットRT」と呼びます。
Now suppose that VPN-S contains some extranet C-sources and VPN-R contains some extranet C-receivers that are allowed by policy to receive extranet C-flows from the VPN-S extranet C-sources.
ここで、VPN-SにエクストラネットCソースがいくつか含まれ、VPN-Rに、ポリシーによってVPN-SエクストラネットCソースからエクストラネットCフローを受信できるエクストラネットCレシーバーがいくつか含まれているとします。
To set up this S-to-R extranet, provisioning an additional RT (call it "RT-S-to-R") whose value is, in general, distinct from RT-S and RT-R is REQUIRED.
このS-to-Rエクストラネットをセットアップするには、追加のRT（「RT-S-to-R」と呼びます）をプロビジョニングします。その値は、一般に、RT-Sとは異なり、RT-Rが必要です。
A VPN-S VRF that contains extranet C-sources allowed to transmit to VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT".
VPN-Rへの送信が許可されているエクストラネットCソースを含むVPN-S VRFは、「発信エクストラネットRT」としてRT-S-to-Rで構成する必要があります。
A VPN-R VRF that contains extranet C-receivers allowed to receive packets from VPN-S MUST be configured with RT-S-to-R as an "Incoming Extranet RT".
VPN-Sからのパケットの受信を許可されたエクストラネットCレシーバーを含むVPN-R VRFは、RT-S-to-Rを「着信エクストラネットRT」として設定する必要があります。
Note that the terms "Incoming" and "Outgoing" in this context refer to the direction of multicast data packets relative to the VRF.
このコンテキストでの「着信」および「発信」という用語は、VRFに対するマルチキャストデータパケットの方向を指すことに注意してください。
The Incoming Extranet RTs and Outgoing Extranet RTs that are configured for a given VRF serve as import RTs for that VRF. They also serve as export RTs, but only for specific routes as specified in Section 6.1.2 below.
特定のVRFに対して構成されている受信エクストラネットRTと送信エクストラネットRTは、そのVRFのインポートRTとして機能します。それらはエクスポートRTとしても機能しますが、以下のセクション6.1.2で指定されている特定のルートに対してのみです。
Note that any VRF that contains both extranet C-sources and extranet C-receivers MUST be configured with both Outgoing Extranet RTs and Incoming Extranet RTs.
エクストラネットCソースとエクストラネットCレシーバーの両方を含むVRFは、発信エクストラネットRTと着信エクストラネットRTの両方で構成する必要があることに注意してください。
A VRF MAY be configured with more than one Incoming Extranet RT and/or Outgoing Extranet RT.
VRFは、複数の受信エクストラネットRTまたは送信エクストラネットRT、あるいはその両方で構成できます。
If it happens to be the case that all C-sources in VPN-S are extranet C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be configured such that RT-S is both a non-extranet RT and an Outgoing Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an Incoming Extranet RT.
VPN-S内のすべてのCソースがVPN-Rへの送信が許可されているエクストラネットCソースである場合は、RT-Sが非エクストラネットRTであるようにVPN-S VRFを構成できます。発信エクストラネットRT、およびVPN-R VRFは、RT-Sが着信エクストラネットRTになるように構成できます。
Suppose that R1 is a route exported from a VPN-S VRF and matching an extranet C-source that is allowed by policy to transmit to VPN-R. In that case, R1 MUST carry the Outgoing Extranet RT used for the S-to-R extranet. This will cause the route to be imported into the VPN-R VRFs that have extranet C-receivers that are allowed by policy to receive from VPN-S.
R1がVPN-S VRFからエクスポートされたルートであり、ポリシーによってVPN-Rへの送信が許可されているエクストラネットCソースと一致するとします。その場合、R1はS-to-Rエクストラネットに使用される発信エクストラネットRTを伝送する必要があります。これにより、ポリシーによってVPN-Sからの受信が許可されているエクストラネットCレシーバーを持つVPN-R VRFにルートがインポートされます。
The rules of Section 4 regarding RTs and ambiguous addresses still apply.
RTとあいまいなアドレスに関するセクション4のルールは引き続き適用されます。
Suppose that a PIM control message (call it "M") is received by a given VRF (call it "VRF-V") from a particular P-tunnel T. In order to process control message M, the PIM C-instance associated with VRF-V may need to do an "RPF determination" (see Section 5.2.2 of [RFC6513]) for a particular IP prefix S. RPF determination is based upon the rules for UMH selection as specified in Section 5.1 of [RFC6513].
PIM制御メッセージ（「M」と呼ぶ）が特定のPトンネルTから特定のVRF（「VRF-V」と呼ぶ）によって受信されると仮定します。制御メッセージMを処理するために、関連付けられているPIM CインスタンスVRF-Vでは、特定のIP接頭辞Sに対して「RPF決定」（[RFC6513]のセクション5.2.2を参照）を実行する必要がある場合があります。RPF決定は、[RFC6513]のセクション5.1で指定されているUMH選択のルールに基づいています。
This document specifies an additional constraint on the UMH selection procedure. When doing RPF determination for a PIM control message received over a P-tunnel, a route matching prefix S is not considered to be eligible for UMH selection unless there is an RT (call it "RT1"), configured as one of VRF-V's Outgoing Extranet RTs, such that the following two conditions both hold:
このドキュメントは、UMH選択手順に関する追加の制約を指定します。 Pトンネルを介して受信したPIM制御メッセージのRPF決定を行うとき、プレフィックスSに一致するルートは、VRF-Vの1つとして構成されたRT（「RT1」と呼ぶ）がない限り、UMH選択に適格とは見なされません。発信エクストラネットRT。次の2つの条件が両方とも成立します。
1. The route matching S is exported from VRF-V carrying RT1, and
1. Sに一致するルートは、RT1を伝送するVRF-Vからエクスポートされます。
2. An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been imported into VRF-V, and that I-PMSI A-D route carries RT1.
2. P-tunnel T（PTA内）をアドバタイズするI-PMSI A-DルートがVRF-Vにインポートされ、そのI-PMSI A-DルートはRT1を伝送します。
In this model, if a VPN-S VRF has extranet multicast C-sources and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins the MI-PMSI that VPN-S uses for its non-extranet traffic.
このモデルでは、VPN-S VRFにエクストラネットマルチキャストCソースがあり、VPN-R VRFにエクストラネットマルチキャストCレシーバーがあり、ポリシーによってVPN-S VRFのCソースからの受信が許可されている場合、VPN-R VRFは、VPN-Sが非エクストラネットトラフィックに使用するMI-PMSIに参加します。
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-S MI-PMSI. In the absence of extranet service, this route carries the VRF's non-extranet RT, RT-S. When extranet service is provided (using the "single PMSI per C-flow" model), this route MUST also carry each of the VRF's Outgoing Extranet RTs.
エクストラネットCソースを持つVPN-S VRFを検討してください。 [RFC6513]に従い、各VPN-S VRFは、VPN-S MI-PMSIの一部として使用されるPトンネルを指定するPTAを含むIntra-AS I-PMSI A-Dルートを発信する必要があります。エクストラネットサービスがない場合、このルートはVRFの非エクストラネットRT、RT-Sを伝送します。エクストラネットサービスが提供されている場合（「Cフローごとの単一のPMSI」モデルを使用）、このルートはVRFの各発信エクストラネットRTも伝送する必要があります。
Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-R MI-PMSI. This route carries the VRF's non-extranet RT, RT-R. When extranet service is provided (using the "single PMSI per C-flow" model), the VPN-R VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D route for each Incoming Extranet RT with which it has been configured; each such route will carry exactly one of the configured Incoming Extranet RTs.
エクストラネットCレシーバーを持つVPN-R VRFを検討してください。 [RFC6513]に従い、各VPN-R VRFは、VPN-R MI-PMSIの一部として使用されるPトンネルを指定するPTAを含むIntra-AS I-PMSI A-Dルートを発信する必要があります。このルートは、VRFの非エクストラネットRT、RT-Rを伝送します。エクストラネットサービスが提供される場合（「Cフローごとの単一のPMSI」モデルを使用）、VPN-R VRFは1つ以上の追加のイントラAS I-PMSI A-Dルートも生成する必要があります。構成されている各着信エクストラネットRTに対して、1つの追加のIntra-AS I-PMSI A-Dルートを作成する必要があります。このような各ルートは、構成された受信エクストラネットRTを1つだけ伝送します。
Note that when a VRF originates more than one Intra-AS I-PMSI A-D route, each of them MUST contain a different RD in its NLRI. In addition, we add the requirement that any pair of such routes MUST NOT contain an RT in common.
VRFが複数のIntra-AS I-PMSI A-Dルートを発信する場合、それぞれのNLRIに異なるRDが含まれている必要があることに注意してください。さらに、そのようなルートのどのペアにも共通のRTを含めてはならないという要件を追加します。
A VRF with extranet C-sources MUST join the P-tunnels advertised in the imported I-PMSI A-D routes that carry its non-extranet RT or any of its Outgoing Extranet RTs. This set of P-tunnels will be treated as instantiating a single MI-PMSI; the associated PIM C-instance will treat that MI-PMSI as a single LAN and will run PIM procedures on that LAN, as specified in [RFC6513]. The fact that the MI-PMSI attaches to VRFs of different VPNs is not known to the PIM C-instance of the VRF containing the sources.
エクストラネットCソースを持つVRFは、その非エクストラネットRTまたはその任意の発信エクストラネットRTを運ぶインポートされたI-PMSI A-DルートでアドバタイズされるPトンネルに参加する必要があります。このPトンネルのセットは、単一のMI-PMSIをインスタンス化するものとして扱われます。 [RFC6513]で指定されているように、関連するPIM CインスタンスはそのMI-PMSIを単一のLANとして扱い、そのLAN上でPIMプロシージャを実行します。 MI-PMSIが異なるVPNのVRFに接続するという事実は、ソースを含むVRFのPIM Cインスタンスにはわかりません。
A VRF with extranet C-receivers MUST join the P-tunnels advertised in all the imported I-PMSI A-D routes. The set of P-tunnels advertised in the I-PMSI A-D routes that carry a particular Incoming Extranet RT are treated as instantiating a particular MI-PMSI. So, a VRF with C-receivers will "see" several MI-PMSIs, one corresponding to the non-extranet, and as many as one for each configured Incoming Extranet RT. The PIM C-instance associated with the VRF will treat each of these MI-PMSIs as a separate LAN interface.
エクストラネットCレシーバーを備えたVRFは、インポートされたすべてのI-PMSI A-DルートでアドバタイズされるPトンネルに参加する必要があります。特定の着信エクストラネットRTを伝送するI-PMSI A-DルートでアドバタイズされるPトンネルのセットは、特定のMI-PMSIをインスタンス化するものとして扱われます。したがって、Cレシーバーを備えたVRFは、複数のMI-PMSIを「認識」します。1つは非エクストラネットに対応し、設定された受信エクストラネットRTごとに1つです。 VRFに関連付けられたPIM Cインスタンスは、これらのMI-PMSIのそれぞれを個別のLANインターフェイスとして扱います。
As an example, suppose that:
例として、次のことを想定します。
o All VPN-R VRFs are configured with RT-R as a non-extranet import and export RT, and
o すべてのVPN-R VRFはRT-Rで非エクストラネットインポートおよびエクスポートRTとして構成され、
o VPN-R VRFs with extranet receivers are configured with RT-S-to-R as an Incoming Extranet RT, and
o エクストラネットレシーバーを備えたVPN-R VRFは、受信エクストラネットRTとしてRT-S-to-Rで構成され、
o VPN-S VRFs with extranet transmitters are configured with:
o エクストラネットトランスミッタを備えたVPN-S VRFは、次のように構成されます。
* RT-S as a non-extranet import and export RT
* 非エクストラネットインポートおよびエクスポートRTとしてのRT-S
* a list of IP addresses that are the addresses of the extranet sources
* エクストラネットソースのアドレスであるIPアドレスのリスト
* RT-S-to-R as an Outgoing Extranet RT
* 発信エクストラネットRTとしてのRT-S-to-R
VPN-S VRFs will then export UMH-eligible routes matching extranet C-sources, and these routes will carry both RT-S and RT-S-to-R. Each VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries both RT-S and RT-S-to-R.
VPN-S VRFは、エクストラネットCソースと一致するUMH適格ルートをエクスポートし、これらのルートはRT-SとRT-S-to-Rの両方を伝送します。各VPN-S VRFは、RT-SとRT-S-to-Rの両方を伝送するIntra-AS I-PMSI A-Dルートもエクスポートします。
VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: one carrying RT-R and one carrying RT-S-to-R. The Intra-AS I-PMSI A-D route with RT-S-to-R will be imported into the VPN-S VRFs.
VPN-R VRFは、RT-Rを伝送するルートとRT-S-to-Rを伝送するルートの2つのIntra-AS I-PMSI A-Dルートを開始およびエクスポートします。 RT-S-to-Rを使用したIntra-AS I-PMSI A-DルートがVPN-S VRFにインポートされます。
VPN-R will regard all the I-PMSI A-D routes it has exported or imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will regard all the I-PMSI A-D routes it has exported or imported with RT-R as part of a second MI-PMSI. The PIM C-instance associated with a VPN-R VRF will treat the two MI-PMSIs as two separate LAN interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D routes imported with RT-S or RT-S-to-R as establishing only a single MI-PMSI. One can think of this as follows: the VPN-R VRFs have joined the VPN-S MI-PMSI as well as the VPN-R MI-PMSI.
VPN-Rは、RT-S-to-RでエクスポートまたはインポートしたすべてのI-PMSI A-Dルートを単一のMI-PMSIの一部と見なします。 VPN-Rは、RT-RでエクスポートまたはインポートしたすべてのI-PMSI A-Dルートを2番目のMI-PMSIの一部と見なします。 VPN-R VRFに関連付けられたPIM Cインスタンスは、2つのMI-PMSIを2つの別個のLANインターフェイスとして扱います。ただし、VPN-S VRFは、RT-SまたはRT-S-to-RでインポートされたすべてのI-PMSI A-Dルートを単一のMI-PMSIのみを確立していると見なします。これは次のように考えることができます。VPN-RVRFは、VPN-S MI-PMSIおよびVPN-R MI-PMSIに参加しています。
Extranets consisting of more than two VPNs are easily supported as follows. Suppose that there are three VPNs: VPN-A, VPN-B, and VPN-C. VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers for both VPN-A extranet C-sources and VPN-B extranet C-sources. In this case, the VPN-C VRFs that have receivers for both VPN-A and VPN-B sources may be provisioned as follows. These VPN-C VRFs may be provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs that are so provisioned will originate three Intra-AS I-PMSI A-D routes (each with a different RD in its NLRI), each of which carries exactly one of the three RTs just mentioned. The VPN-B VRFs with extranet C-sources will be provisioned with RT-B-to-C as an Outgoing Extranet RT, and the VPN-A VRFs will be provisioned with RT-A-to-C as an Outgoing Extranet RT. The result will be that the PIM C-instance associated with a VPN-C VRF will see three LAN interfaces: one for the non-extranet and one for each of the two extranets. This generalizes easily to the case where there are VPN-C receivers in n different extranets (i.e., receiving extranet flows whose sources are in n different VPNs).
3つ以上のVPNで構成されるエクストラネットは、次のように簡単にサポートされます。 VPN-A、VPN-B、VPN-Cの3つのVPNがあるとします。 VPN-AとVPN-BにはエクストラネットCソースがあり、VPN-CにはVPN-AエクストラネットCソースとVPN-BエクストラネットCソースの両方のレシーバーが含まれています。この場合、VPN-AとVPN-Bの両方のソースのレシーバーを持つVPN-C VRFは、次のようにプロビジョニングできます。これらのVPN-C VRFは、RT-Cを非エクストラネットRTとして、RT-A-to-CおよびRT-B-to-Cを着信エクストラネットRTとしてプロビジョニングできます。この場合、そのようにプロビジョニングされたVPN-C VRFは、3つのIntra-AS I-PMSI A-Dルート（それぞれがNLRIで異なるRDを持つ）を発信し、それぞれが前述の3つのRTの1つを正確に伝送します。エクストラネットCソースを備えたVPN-B VRFは、RT-B-to-Cで発信エクストラネットRTとしてプロビジョニングされ、VPN-A VRFはRT-A-to-Cで発信エクストラネットRTとしてプロビジョニングされます。その結果、VPN-C VRFに関連付けられたPIM Cインスタンスには3つのLANインターフェイスが表示されます。1つは非エクストラネット用、もう1つは2つのエクストラネット用です。これは、n個の異なるエクストラネットにVPN-Cレシーバーがある場合（つまり、ソースがn個の異なるVPNにあるエクストラネットフローを受信する場合）に簡単に一般化されます。
Suppose again that there are three VPNs -- VPN-A, VPN-B, and VPN-C -- but in this example VPN-A is the only one with extranet sources while VPN-B and VPN-C both have receivers for the VPN-A extranet sources. This can be provisioned as either one extranet or two extranets.
ここでも、VPN-A、VPN-B、VPN-Cの3つのVPNがあるとしますが、この例では、VPN-Aがエクストラネットソースを持つ唯一のVPNであり、VPN-BとVPN-Cの両方にVPN-Aエクストラネットソース。これは、1つのエクストラネットまたは2つのエクストラネットとしてプロビジョニングできます。
To provision it as one extranet, the VPN-A VRFs are configured with one Outgoing Extranet RT (call it "RT-A-extranet"). The VPN-B and VPN-C VRFs with extranet receivers will be provisioned with RT-A-extranet as the Incoming Extranet RT. Thus, the VPN-B and VPN-C VRFs will each originate two Intra-AS I-PMSI A-D routes: one for the non-extranet and one for the extranet. From a given VRF, the Intra-AS I-PMSI A-D route for the extranet will carry RT-A-extranet but will not share any RT with the non-extranet A-D routes exported from the same VRF.
1つのエクストラネットとしてプロビジョニングするために、VPN-A VRFは1つの発信エクストラネットRT（「RT-A-エクストラネット」と呼ばれます）で構成されています。エクストラネットレシーバーを備えたVPN-BおよびVPN-C VRFは、着信エクストラネットRTとしてRT-A-エクストラネットでプロビジョニングされます。したがって、VPN-BおよびVPN-C VRFはそれぞれ、2つのIntra-AS I-PMSI A-Dルートを発信します。1つは非エクストラネット用で、もう1つはエクストラネット用です。特定のVRFから、エクストラネットのイントラAS I-PMSI A-DルートはRT-A-エクストラネットを伝送しますが、同じVRFからエクスポートされた非エクストラネットA-DルートとRTを共有しません。
The result is that the VPN-B and VPN-C VRFs each belong to two MI-PMSIs: one for the extranet and one for the intranet. The MI-PMSI for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs.
その結果、VPN-BおよびVPN-C VRFはそれぞれ2つのMI-PMSIに属します。1つはエクストラネット用で、もう1つはイントラネット用です。エクストラネットのMI-PMSIは、VPN-A VRF、VPN-B VRF、およびVPN-C VRFを接続します。
Alternatively, one could provision the VPN-A VRFs so that some UMH-eligible extranet source routes carry an RT that we will call "RT-A-to-B" and some carry an RT that we will call "RT-A-to-C". The VPN-A VRFs would be configured with both of these as Outgoing Extranet RTs. To allow an extranet flow from a VPN-A source to have both VPN-B and VPN-C receivers, the UMH-eligible route for that source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an Incoming Extranet RT.
または、VPN-A VRFをプロビジョニングして、UMH対応のエクストラネットソースルートに「RT-A-to-B」と呼ばれるRTを運び、一部に「RT-A-to」と呼ばれるRTを運ばせることもできます。 -C」。 VPN-A VRFは、これらの両方で発信エクストラネットRTとして構成されます。 VPN-AソースからのエクストラネットフローがVPN-BとVPN-Cの両方のレシーバーを持つことができるようにするには、そのソースのUMH対応ルートが両方のRTを伝送します。 VPN-B VRF（VPN-C VRFではない）は、受信エクストラネットRTとしてRT-A-to-Bでプロビジョニングされます。 VPN-C VRF（VPN-B VRFではない）は、RT-A-to-Cで着信エクストラネットRTとしてプロビジョニングされます。
Following the rules above, if any VPN-A extranet source is to have both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each originate two I-PMSI A-D routes: one for the extranet and one for the non-extranet. The single Intra-AS I-PMSI A-D route originated by the VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route originated from a VPN-B VRF would have RT-A-to-B, and the extranet I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C.
上記のルールに従って、VPN-AエクストラネットソースにVPN-BレシーバーとVPN-Cレシーバーの両方がある場合、VPN-BおよびVPN-C VRFはそれぞれ2つのI-PMSI ADルートを生成します。1つはエクストラネット用で、もう1つはエクストラネット用です。非エクストラネット用。 VPN-A VRFによって発信された単一のIntra-AS I-PMSI ADルートには、RT間にRT-A-to-BとRT-A-to-Cの両方（およびVPN-Aの非エクストラネットRT）があります。 。 VPN-B VRFから発信されたエクストラネットI-PMSI A-DルートにはRT-A-to-Bがあり、VPN-C VRFから発信されたエクストラネットI-PMSI A-DルートにはRT-A-to-Cがあります。
If a given VRF contains both extranet C-receivers and extranet C-sources, the procedures described above still work, as the VRF will be configured with both Incoming Extranet RTs and Outgoing Extranet RTs; the VRF functions as both a VPN-S VRF and a VPN-R VRF.
特定のVRFにエクストラネットCレシーバーとエクストラネットCソースの両方が含まれている場合、VRFは受信エクストラネットRTと送信エクストラネットRTの両方で構成されるため、上記の手順は引き続き機能します。 VRFは、VPN-S VRFとVPN-R VRFの両方として機能します。
When PIM is used as the PE-PE C-multicast control plane, every S-PMSI is considered to be part of the "emulated LAN" that "corresponds" to a particular MI-PMSI.
PIMがPE-PE Cマルチキャストコントロールプレーンとして使用される場合、すべてのS-PMSIは、特定のMI-PMSIに「対応する」「エミュレートされたLAN」の一部と見なされます。
When the bindings of C-flows to particular S-PMSIs are announced via S-PMSI Join messages (Section 7 of [RFC6513]) sent on the MI-PMSI, the S-PMSI is considered to be part of the same LAN interface as the corresponding MI-PMSI.
特定のS-PMSIへのCフローのバインディングがMI-PMSIで送信されるS-PMSI Joinメッセージ（[RFC6513]のセクション7）を介してアナウンスされる場合、S-PMSIは、対応するMI-PMSI。
When the bindings of C-flows to particular S-PMSIs are announced via S-PMSI A-D routes, any S-PMSI A-D route exported from that VRF MUST have an RT in common with exactly one of the Intra-AS A-D routes exported from that VRF, and this MUST be one of the VRF's Outgoing Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in common with any other Intra-AS A-D route exported from a VRF on the same PE. A given S-PMSI A-D route will be considered to "correspond" to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the same PE) with which it shares an RT.
特定のS-PMSIへのCフローのバインディングがS-PMSI ADルートを介してアナウンスされる場合、そのVRFからエクスポートされたすべてのS-PMSI ADルートは、そこからエクスポートされたAS内ADルートの1つと共通のRTを持つ必要がありますVRF、これはVRFの発信エクストラネットRTの1つでなければなりません。さらに、S-PMSI A-Dルートには、同じPE上のVRFからエクスポートされた他のIntra-AS A-Dルートと共通のRTがあってはなりません。特定のS-PMSI A-Dルートは、RTを共有する（同じPEから発信された）Intra-AS I-PMSI A-DルートのMI-PMSIに「対応」すると見なされます。
The MI-PMSI that corresponds to a given S-PMSI is determined as follows:
特定のS-PMSIに対応するMI-PMSIは、次のように決定されます。
o If (1) there is an Intra-AS I-PMSI A-D route originated by the same PE that originated the S-PMSI A-D route, (2) those two routes have an RT in common, and (3) that RT is one of the VRF's Incoming Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated with that Intra-AS I-PMSI A-D route.
o （1）S-PMSI ADルートを発信した同じPEによって発信されたAS内I-PMSI ADルートが存在する場合、（2）これら2つのルートには共通のRTがあり、（3）RTはVRFの着信エクストラネットRTの場合、S-PMSIは、そのIntra-AS I-PMSI ADルートに関連付けられたI-PMSIに対応します。
o Otherwise, if (1) there is an Inter-AS I-PMSI A-D route originated in the same AS as the S-PMSI A-D route, (2) those two routes have an RT in common, and (3) that RT is one of the VRF's Incoming Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated with that Inter-AS I-PMSI A-D route.
o それ以外の場合、（1）S-PMSI ADルートと同じASから発信されたInter-AS I-PMSI ADルートがある場合、（2）これら2つのルートには共通のRTがあり、（3）RTは1 VRFの受信エクストラネットRTの場合、S-PMSIはそのInter-AS I-PMSI ADルートに関連付けられたI-PMSIに対応します。
o Otherwise, there must be a configuration error (a violation of the requirements of Sections 3, 4, and 5 of this document).
o それ以外の場合は、構成エラー（このドキュメントのセクション3、4、および5の要件の違反）が存在する必要があります。
When wildcard S-PMSIs are used, the rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows:
ワイルドカードS-PMSIが使用される場合、特定のS-PMSI ADルートが特定の（CS、CG）または（C-*、CG）に対する「受信の一致」であるかどうかを決定するための[RFC6625]で指定されたルールが変更されます次のように：
A given S-PMSI A-D route MUST NOT be considered to be a "match for reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI that is the incoming interface for the given state.
特定のS-PMSI ADルートは、S-PMSI ADルートが「対応する」（上記で定義されている）場合を除き、特定の（CS、CG）または（C-*、CG）状態の「受信の一致」と見なしてはなりません（MUST NOT）。 ）指定された状態の受信インターフェースであるMI-PMSIに。
The rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for transmission" are unchanged.
[RFC6625]で与えられた、与えられたS-PMSI A-Dルートが「送信用の一致」であるかどうかを決定するためのルールは変更されていません。
Suppose that a PE, say PE1, receives a PIM Join(S,G) from a CE, over a VRF interface that is associated with a VPN-R VRF. The PE does the RPF check for S by looking up S in the VPN-R VRF. The PIM C-instance associated with that VRF must determine the correct P-tunnel over which to send a PIM Join(S,G) to other PEs.
PE、たとえばPE1が、VPN-R VRFに関連付けられているVRFインターフェイスを介してCEからPIM Join（S、G）を受信するとします。 PEは、VPN-R VRFでSを検索して、SのRPFチェックを実行します。そのVRFに関連付けられたPIM Cインスタンスは、PIM Join（S、G）を他のPEに送信する正しいPトンネルを決定する必要があります。
To do this, PE1 finds, in the VRF associated with the interface over which the Join was received, the selected UMH route for S, following the procedures of Section 5.1 of [RFC6513]. PE1 determines the set of RTs carried by that route. PE1 then checks to see if there is an Intra-AS I-PMSI A-D route, currently originated by PE1, that has an RT in common with the selected UMH route for S.
これを行うために、PE1は、[RFC6513]のセクション5.1の手順に従って、Joinを受信したインターフェースに関連付けられたVRFで、選択されたSのUMHルートを見つけます。 PE1は、そのルートで伝送されるRTのセットを決定します。次に、PE1は、現在PE1によって開始された、ASの選択されたUMHルートと共通のRTを持つIntra-AS I-PMSI A-Dルートがあるかどうかを確認します。
If the rules of Sections 3, 4, and 5 have been followed, each of PE1's selected UMH routes will share an RT with a single one of PE1's currently originated Intra-AS I-PMSI A-D routes. If this is so, the Join is sent on the P-tunnel advertised in the PTA of that route. Otherwise, the Join MUST NOT be sent.
セクション3、4、および5のルールが守られている場合、PE1の選択された各UMHルートは、PE1が現在発信しているIntra-AS I-PMSI A-Dルートの1つとRTを共有します。その場合、そのルートのPTAでアドバタイズされたPトンネルでJoinが送信されます。それ以外の場合、Joinを送信してはなりません（MUST NOT）。
In essence, this procedure makes the RPF check for C-S resolve to the MI-PMSI that is serving as the next-hop "interface" to C-S.
本質的に、この手順では、C-SのRPFチェックを、C-Sへのネクストホップ「インターフェース」として機能しているMI-PMSIに解決します。
If a PE receives a PIM Join(*,G) from a CE, the procedure for doing the RPF check is the same, except that the selected UMH route will be a route to the C-RP associated with the C-G group.
PEがCEからPIM Join（*、G）を受信した場合、RPFチェックを実行する手順は同じですが、選択したUMHルートがC-Gグループに関連付けられたC-RPへのルートになる点が異なります。
When a PIM C-instance receives a PIM control message from a P-tunnel, it needs to identify the message's incoming interface. This incoming interface is the MI-PMSI of which the P-tunnel is a part.
PIM Cインスタンスは、PトンネルからPIM制御メッセージを受信すると、メッセージの着信インターフェイスを識別する必要があります。この着信インターフェースは、Pトンネルがその一部であるMI-PMSIです。
The rules for choosing the PMSI on which to send a multicast data packet are as specified in [RFC6513] and [RFC6625], with one new restriction: a VPN-S VRF always transmits a multicast data packet either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is only one outgoing interface.
マルチキャストデータパケットを送信するPMSIを選択するためのルールは、[RFC6513]と[RFC6625]で指定されているとおりです。ただし、VPN-S VRFは常にVPN-S MI-でマルチキャストデータパケットを送信します。 PMSIまたはVPN-S MI-PMSIに対応するS-PMSI。 PIM Cインスタンスの観点から見ると、発信インターフェースは1つしかありません。
When a PIM C-instance receives a multicast data packet from a given P-tunnel and that P-tunnel is being used to instantiate an MI-PMSI, the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and 6.2.2) is considered to be the packet's incoming interface. If the packet is received on a P-tunnel that was advertised in an S-PMSI A-D route, the packet's incoming interface is the MI-PMSI to which that S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM rules for data-plane RPF checks apply.
PIM Cインスタンスが特定のPトンネルからマルチキャストデータパケットを受信し、そのPトンネルがMI-PMSIのインスタンス化に使用されている場合、Pトンネルがその一部であるMI-PMSI（セクション6.2を参照）。 1および6.2.2）は、パケットの着信インターフェースと見なされます。パケットがS-PMSI A-DルートでアドバタイズされたPトンネルで受信された場合、パケットの着信インターフェイスは、セクション6.2.2で定義されているように、そのS-PMSIルートが対応するMI-PMSIです。データプレーンRPFチェックの通常のPIMルールが適用されます。
Following ordinary PIM procedures, packets arriving from an unexpected incoming interface are discarded. This eliminates any problems due to the ambiguities described in Sections 2.1 and 2.2.
通常のPIM手順に従って、予期しない着信インターフェイスから到着したパケットは破棄されます。これにより、セクション2.1および2.2で説明されているあいまいさによる問題がなくなります。
In this model, if a VPN-S VRF has extranet multicast C-sources and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins the MI-PMSI that VPN-R uses for its non-extranet traffic.
このモデルでは、VPN-S VRFにエクストラネットマルチキャストCソースがあり、VPN-R VRFにエクストラネットマルチキャストCレシーバーがあり、ポリシーによってVPN-S VRFのCソースからの受信が許可されている場合、VPN-S VRFは、VPN-Rが非エクストラネットトラフィックに使用するMI-PMSIに参加します。
In the "single PMSI per C-flow" transmission model (as described in Section 6.2), a PE that needs to transmit a multicast data packet to a set of other PEs transmits the packet on a single PMSI. This means that if a packet needs to be transmitted from a VPN-A VRF and received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel from which the VPN-B and VPN-C VRFs can both receive packets.
「Cフローごとの単一PMSI」伝送モデル（セクション6.2で説明）では、マルチキャストデータパケットを他のPEのセットに送信する必要があるPEが、単一のPMSIでパケットを送信します。これは、パケットがVPN-A VRFから送信され、VPN-B VRFおよびVPN-C VRFで受信される必要がある場合、VPN-BおよびVPN-C VRFが送信できるPトンネルが存在する必要があることを意味します。どちらもパケットを受信します。
In the "multiple PMSIs per C-flow" transmission model, a PE that needs to transmit a multicast data packet to a set of other PEs may transmit the packet on several different PMSIs. (Of course, any given packet is transmitted only once on a given P-tunnel.) For example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B receiver, and a VPN-C receiver, there could be one PMSI that the VPN-A VRF uses to transmit the packet to the VPN-B VRFs and another PMSI that the VPN-A VRF uses to transmit the packet to the VPN-C VRFs.
「Cフローごとの複数のPMSI」送信モデルでは、マルチキャストデータパケットを他のPEのセットに送信する必要があるPEは、いくつかの異なるPMSIでパケットを送信できます。 （もちろん、特定のパケットは特定のPトンネルで1回だけ送信されます。）たとえば、Cフロー（CS、CG）にVPN-A Cソース、VPN-Bレシーバー、およびVPNがある場合-Cレシーバー。VPN-AVRFがVPN-B VRFにパケットを送信するために使用する1つのPMSIと、VPN-A VRFがVPN-C VRFにパケットを送信するために使用する別のPMSIが存在する可能性があります。
Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-R MI-PMSI. In the absence of extranet service, this route carries the VRF's non-extranet RT, RT-R. When extranet service is provided (using the "single PMSI per C-flow" model), this route MUST also carry each of the VRF's Incoming Extranet RTs.
エクストラネットCレシーバーを持つVPN-R VRFを検討してください。 [RFC6513]に従い、各VPN-R VRFは、VPN-R MI-PMSIの一部として使用されるPトンネルを指定するPTAを含むIntra-AS I-PMSI A-Dルートを発信する必要があります。エクストラネットサービスがない場合、このルートはVRFの非エクストラネットRT、RT-Rを伝送します。エクストラネットサービスが提供される場合（「Cフローごとの単一PMSI」モデルを使用）、このルートはVRFの着信エクストラネットRTのそれぞれも伝送する必要があります。
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-S MI-PMSI. This route carries the VRF's non-extranet RT, RT-S. When extranet service is provided using the "multiple PMSIs per C-flow" model, the VPN-S VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D route for each Outgoing Extranet RT with which it has been configured; each such route will have a distinct RD and will carry exactly one of the configured Outgoing Extranet RTs.
エクストラネットCソースを持つVPN-S VRFを検討してください。 [RFC6513]に従い、各VPN-S VRFは、VPN-S MI-PMSIの一部として使用されるPトンネルを指定するPTAを含むIntra-AS I-PMSI A-Dルートを発信する必要があります。このルートは、VRFの非エクストラネットRT、RT-Sを伝送します。 「Cフローごとの複数のPMSI」モデルを使用してエクストラネットサービスを提供する場合、VPN-S VRFは1つ以上の追加のIntra-AS I-PMSI A-Dルートも生成する必要があります。それはそれが設定されたそれぞれの発信エクストラネットRTのために1つの追加のイントラAS I-PMSI A-Dルートを生成しなければなりません。このような各ルートには個別のRDがあり、構成済みの発信エクストラネットRTの1つだけを伝送します。
As with the "single PMSI per C-flow" transmission model, VRFs containing extranet C-receivers need to import UMH-eligible extranet C-source routes from VRFs containing C-sources. This is ensured by the rules of Sections 3, 4, and 5.
「Cフローごとの単一PMSI」伝送モデルと同様に、エクストラネットCレシーバーを含むVRFは、Cソースを含むVRFからUMHに適格なエクストラネットCソースルートをインポートする必要があります。これは、セクション3、4、および5のルールによって保証されます。
However, in the "multiple PMSIs per C-flow" model, a VRF containing only C-receivers originates only a single Intra-AS I-PMSI A-D route carrying the non-extranet RT and all the Incoming Extranet RTs.
ただし、「Cフローごとの複数のPMSI」モデルでは、Cレシーバーのみを含むVRFは、非エクストラネットRTとすべての着信エクストラネットRTを運ぶ単一のイントラAS I-PMSI A-Dルートのみを発信します。
When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes that carry the non-extranet RT or one of the Incoming Extranet RTs, the P-tunnels specified in the PTA of all such routes are considered to be part of the same MI-PMSI. That is, the associated PIM C-instance will treat them as part of a single interface.
Cレシーバーを含むVRFが、非エクストラネットRTまたは着信エクストラネットRTの1つを伝送するIntra-AS I-PMSI ADルートをインポートする場合、そのようなすべてのルートのPTAで指定されたPトンネルは、同じMI-PMSI。つまり、関連するPIM Cインスタンスは、それらを単一のインターフェースの一部として扱います。
In this model, it is the VRF containing extranet C-sources that MUST originate multiple Intra-AS I-PMSI A-D routes. Each such route MUST have a distinct RD, and the set of RTs carried by any one of these routes MUST be disjoint from the set carried by any other. There MUST be one such route for each of the VRF's Outgoing Extranet RTs, and each such route MUST carry exactly one of the VRF's Outgoing Extranet RTs. The VRFs containing extranet C-sources MUST also import all the A-D routes originated by the VRFs containing extranet C-receivers. If a set of originated and/or imported Intra-AS I-PMSI A-D routes have an RT in common and that RT is one of the VRF's Outgoing Export RTs, then those routes are considered to be "about" the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI as a LAN interface.
このモデルでは、複数のIntra-AS I-PMSI A-Dルートを発信する必要があるのは、エクストラネットCソースを含むVRFです。そのような各ルートは別個のRDを持たなければならず（MUST）、これらのルートのいずれか1つによって運ばれるRTのセットは、他のルートによって運ばれたセットから切り離されている必要があります。 VRFの発信エクストラネットRTごとにそのようなルートが1つ必要であり、そのような各ルートは、VRFの発信エクストラネットRTを1つだけ運ぶ必要があります。エクストラネットCソースを含むVRFは、エクストラネットCレシーバーを含むVRFから発信されたすべてのA-Dルートもインポートする必要があります。一連の発信および/またはインポートされたIntra-AS I-PMSI A-Dルートに共通のRTがあり、そのRTがVRFの発信エクスポートRTの1つである場合、それらのルートは同じMI-PMSIと「見なされる」と見なされます。 VRFのPIM Cインスタンスは、各MI-PMSIをLANインターフェイスとして扱います。
In effect, if VPN-S has only extranet C-sources and VPN-R has only extranet C-receivers, this model has the VPN-S VRFs join the VPN-R MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, while the VPN-R VRFs are attached to only one. The fact that the VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM C-instance at the VPN-R VRFs.
実際、VPN-SにエクストラネットCソースのみがあり、VPN-RにエクストラネットCレシーバーしかない場合、このモデルにはVPN-S VRFがVPN-R MI-PMSIに参加します。したがって、VPN-S VRFは複数のMI-PMSIに接続されますが、VPN-R VRFは1つだけに接続されます。 VPN-R MI-PMSIがVPN-S VRFに接続されているという事実は、VPN-R VRFのPIM Cインスタンスにはわかりません。
If a VPN-A VRF has extranet C-sources allowed to send to C-receivers in a VPN-B VRF and the VPN-B VRF has C-sources allowed to send to C-receivers in the VPN-A VRF, the above procedures still work as specified.
VPN-A VRFに、VPN-B VRFのCレシーバーへの送信が許可されているエクストラネットCソースがあり、VPN-B VRFがVPN-A VRFのCレシーバーへの送信を許可されているCソースがある場合、上記手順はまだ指定どおりに機能します。
Following normal PIM procedures, when the PIM C-instance at a VRF with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the MI-PMSI over which the Join was received may be added to the set of outgoing interfaces for that multicast state. If n MI-PMSIs are added to the outgoing interface list for a particular multicast state, a multicast data packet may need to be replicated n times and transmitted once on each of the n MI-PMSIs.
通常のPIM手順に従って、エクストラネットCソースのあるVRFのPIM CインスタンスがMI-PMSIを介してJoin（CS、CG）またはJoin（C-*、CG）を受信すると、（CS、CG ）または（C-*、CG）状態、および結合が受信されたMI-PMSIは、そのマルチキャスト状態の発信インターフェースのセットに追加されます。 n個のMI-PMSIが特定のマルチキャスト状態の発信インターフェイスリストに追加される場合、マルチキャストデータパケットはn回複製され、n個のMI-PMSIのそれぞれで1回送信される必要があります。
Since all of the multicast data packets received from another PE are received over a single emulated LAN, it is not necessary to have any special procedures to determine a packet's incoming interface. The ambiguities described in Sections 2.1 and 2.2 do not occur, because a VPN-R VRF can only receive multicast data traffic that has been requested by a VPN-R VRF.
別のPEから受信したすべてのマルチキャストデータパケットは単一のエミュレートされたLAN経由で受信されるため、パケットの着信インターフェイスを判別するために特別な手順を実行する必要はありません。 VPN-R VRFはVPN-R VRFによって要求されたマルチキャストデータトラフィックしか受信できないため、セクション2.1および2.2で説明されているあいまいさは発生しません。
This document assumes that if BGP is used as the PE-PE C-multicast control plane, the "single PMSI per C-flow" model is used. Procedures for providing the "multiple PMSIs per C-flow" model with BGP C-multicast are outside the scope of this document.
このドキュメントでは、BGPがPE-PE Cマルチキャストコントロールプレーンとして使用される場合、「Cフローごとの単一PMSI」モデルが使用されることを前提としています。 「Cフローごとの複数のPMSI」モデルにBGP Cマルチキャストを提供する手順は、このドキュメントの範囲外です。
When BGP is used as the C-multicast control plane, the "single PMSI per C-flow" model may be used either with or without extranet separation. (Recall that "extranet separation" means that no P-tunnel can carry traffic from both extranet sources and non-extranet sources.) In either case, the data traffic may be carried on Inclusive Tunnels only, Selective Tunnels only (known as the "S-PMSI only" model), or a combination of Inclusive Tunnels and Selective Tunnels. This is determined by provisioning. The procedures specified below support all three choices.
BGPがCマルチキャストコントロールプレーンとして使用される場合、「Cフローごとの単一PMSI」モデルは、エクストラネット分離の有無にかかわらず使用できます。 （「エクストラネット分離」とは、エクストラネットソースと非エクストラネットソースの両方からトラフィックを伝送できるPトンネルがないことを思い出してください。）どちらの場合でも、データトラフィックは、包含トンネルのみ、選択トンネルのみ（「 S-PMSIのみ」モデル）、またはインクルーシブトンネルとセレクティブトンネルの組み合わせ。これはプロビジョニングによって決定されます。以下に示す手順は、3つの選択肢すべてをサポートしています。
Note that there are no special extranet procedures for Inter-AS I-PMSI A-D routes or for Leaf A-D routes.
Inter-AS I-PMSI A-DルートまたはLeaf A-Dルートには、特別なエクストラネット手順はないことに注意してください。
This section applies whether extranet separation is used or not.
このセクションは、エクストラネット分離が使用されているかどうかに関係なく適用されます。
When it is necessary to originate a C-multicast Source Tree Join for (C-S,C-G), a PE must follow the procedures of Section 11.1.3 ("Constructing the Rest of the C-Multicast Route") of [RFC6514] to find the selected UMH route for C-S. When it is necessary to originate a C-multicast Shared Tree Join for (C-*,C-G), where C-G is an ASM group, a PE must follow the procedures of that section to find the selected UMH route for C-G's C-RP.
（CS、CG）のCマルチキャストソースツリー結合を開始する必要がある場合、PEは、[RFC6514]のセクション11.1.3（「Cマルチキャストルートの残りの構成」）の手順に従って、 CSの選択されたUMHルート。 （C-*、CG）のCマルチキャスト共有ツリー結合を開始する必要がある場合（CGはASMグループ）、PEはそのセクションの手順に従って、CGのC-の選択されたUMHルートを見つける必要があります。 RP。
Section 11.1.3 of [RFC6514] specifies how information from the selected UMH route is used to find an Intra-AS I-PMSI A-D route or an Inter-AS I-PMSI A-D route. Information from that I-PMSI A-D route is then used to construct part of the C-multicast route.
[RFC6514]のセクション11.1.3は、選択されたUMHルートからの情報を使用して、AS内I-PMSI A-DルートまたはAS間I-PMSI A-Dルートを検索する方法を指定します。そのI-PMSI A-Dルートからの情報は、Cマルチキャストルートの一部を構築するために使用されます。
For extranets, the rules given in Section 7.4.5 of this document are used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that "corresponds" to the selected UMH route; the rules in Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514] for finding the Inter-AS or Intra-AS I-PMSI A-D route.
エクストラネットの場合、このドキュメントのセクション7.4.5に示されているルールは、選択されたUMHルートに「対応する」Inter-AS I-PMSI A-DルートまたはIntra-AS I-PMSI A-Dルートを見つけるために使用されます。セクション7.4.5のルールは、Inter-ASまたはIntra-AS I-PMSI A-Dルートを見つけるための[RFC6514]のセクション11.1.3で与えられたルールを置き換えます。
Information from this I-PMSI A-D route is then used, as specified in Section 11.1.3 of [RFC6514], to construct the C-multicast route.
[RFC6514]のセクション11.1.3で指定されているように、このI-PMSI A-Dルートからの情報は、Cマルチキャストルートを構築するために使用されます。
Consider a VRF (call it "VRF-S") that contains extranet C-sources and exports UMH-eligible routes matching those C-sources. The VRF may also originate and export an Intra-AS I-PMSI A-D route.
エクストラネットCソースを含み、それらのCソースに一致するUMH適格ルートをエクスポートするVRF（「VRF-S」と呼ぶ）を検討してください。 VRFは、Intra-AS I-PMSI A-Dルートを開始およびエクスポートすることもできます。
As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route is originated by and exported from VRF-S, the RTs carried by that route MUST be chosen such that every VRF that imports a UMH-eligible route from VRF-S also imports this Intra-AS I-PMSI A-D route.
[RFC6514]で指定されているように、1つのIntra-AS I-PMSI ADルートがVRF-Sによって発信され、そこからエクスポートされる場合、そのルートによって運ばれるRTは、UMF適格ルートをVRFからインポートするすべてのVRFが-Sは、このIntra-AS I-PMSI ADルートもインポートします。
If inclusive P-tunnels are being used to carry extranet C-flows, there are additional requirements on the way the RTs carried by the Intra-AS I-PMSI A-D routes must be chosen, as specified in the following paragraph.
インクルーシブPトンネルがエクストラネットCフローの伝送に使用されている場合、次の段落で指定されているように、Intra-AS I-PMSI A-Dルートによって伝送されるRTを選択する方法には追加の要件があります。
If VRF-S is using inclusive P-tunnels but is not using extranet separation, there is one inclusive P-tunnel rooted at VRF-S, and this tunnel carries both extranet and non-extranet C-flows. This Inclusive Tunnel is identified in the PTA of the Intra-AS I-PMSI A-D route originated from VRF-S. The set of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen so as to ensure that every VRF that imports a UMH-eligible route from this VRF-S also imports this Intra-AS I-PMSI A-D route. Further, the set of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen such that it has at least one RT in common with every UMH-eligible route that is exported from the VRF.
VRF-Sが包括的Pトンネルを使用しているがエクストラネット分離を使用していない場合、VRF-Sをルートとする包括的Pトンネルが1つあり、このトンネルはエクストラネットと非エクストラネットの両方のCフローを伝送します。この包括的トンネルは、VRF-Sから発信されたIntra-AS I-PMSI A-DルートのPTAで識別されます。このVRF-SからUMHに適格なルートをインポートするすべてのVRFがこのIntra-AS I-PMSI A-Dルートもインポートするように、このIntra-AS I-PMSI A-Dルートによって運ばれるRTのセットを選択する必要があります。さらに、このIntra-AS I-PMSI A-Dルートによって運ばれるRTのセットは、VRFからエクスポートされるすべてのUMH適格ルートと共通の少なくとも1つのRTを持つように選択する必要があります。
Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose that R-SP is used to bind some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Let R-UMH be a UMH-eligible route that is exported from VRF-S and matches the given extranet C-source. In that case, R-SP and R-UMH MUST have at least one RT in common. Further, the RTs carried by these two routes MUST be such that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625].
R-SPを、VRF-SからエクスポートされるS-PMSI A-Dルートとします。 R-SPを使用して、特定のエクストラネットCソースから特定の選択的PトンネルにエクストラネットCフローの一部またはすべてをバインドするとします。 R-UMHを、VRF-Sからエクスポートされ、指定されたエクストラネットCソースに一致するUMH適格ルートとします。その場合、R-SPとR-UMHは少なくとも1つのRTを共有する必要があります。さらに、これらの2つのルートによって運ばれるRTは、R-UMHをインポートするすべてのVRFがR-SPもインポートするようなものである必要があります。これらのルールは、R-SPがワイルドカードを使用するかどうかに関係なく適用されます[RFC6625]。
An implementation MUST allow the set of RTs carried by the S-PMSI A-D routes to be specified by configuration. In the absence of such configuration, an S-PMSI A-D route originated by a given VRF, say VRF-X, MUST carry a default set of RTs, as specified by the following rules:
実装は、S-PMSI A-Dルートによって運ばれるRTのセットが構成によって指定されることを許可しなければなりません（MUST）。そのような構成がない場合、特定のVRF、たとえばVRF-Xから発信されたS-PMSI A-Dルートは、次のルールで指定されているように、デフォルトのRTセットを運ぶ必要があります。
1. By default, an S-PMSI A-D route originated by VRF-X for a given (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible route originated by VRF-X that matches C-S.
1. デフォルトでは、特定の（CS、CG）または（CS、C- *）のVRF-Xによって発信されたS-PMSI ADルートは、一致するVRF-Xによって発信されたUMH適格ルートと同じRTを伝送しますCS。
2. By default, an S-PMSI A-D route originated by VRF-X for a given (C-*,C-G) carries as its RTs a set union of all RT(s) of the UMH-eligible route(s) matching the multicast C-sources contained in VRF-X that could originate traffic for that C-G. Moreover, if the VRF contains (as defined in Section 1.1) the C-RP of C-G, then this set union also includes the RT(s) of the UMH-eligible route matching C-RP and the RT(s) of the unicast VPN-IP route matching C-RP.
2. デフォルトでは、特定の（C-*、CG）のVRF-Xによって発信されたS-PMSI ADルートは、そのCRTとして、マルチキャストCに一致するUMH適格ルートのすべてのRTのセットユニオンを運びます-そのCGのトラフィックを発信できるVRF-Xに含まれるソース。さらに、VRFに（セクション1.1で定義されているように）CGのC-RPが含まれている場合、このセットのユニオンには、UMH適格ルートに一致するC-RPのRTとユニキャストのRTも含まれます。 C-RPに一致するVPN-IPルート。
3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X is to be used for both extranet and non-extranet traffic, it carries the same RTs that would be carried (as specified in Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that I-PMSI A-D route were advertising an inclusive P-tunnel for carrying both extranet and non-extranet traffic. In general, a given VRF would not originate both (a) an S-PMSI A-D route advertising a (C-*,C-*) selective P-tunnel for both extranet and non-extranet traffic and (b) an I-PMSI A-D route advertising an inclusive P-tunnel for both extranet and non-extranet traffic, as the inclusive P-tunnel would not get used in that case.
3. デフォルトでは、VRF-Xによって発信された（C-*、C- *）S-PMSI ADルートがエクストラネットトラフィックと非エクストラネットトラフィックの両方に使用される場合、（同じように）運ばれるのと同じRTを運びますセクション7.2.1）I-PMSI ADルートがエクストラネットトラフィックと非エクストラネットトラフィックの両方を伝送するための包括的なPトンネルをアドバタイズしている場合、VRF-Xによって発信されたI-PMSI ADルート。一般に、特定のVRFは、（a）エクストラネットトラフィックと非エクストラネットトラフィックの両方に対して（C-*、C- *）選択的PトンネルをアドバタイズするS-PMSI ADルートと、（b）I-PMSIの両方を発信しません。エクストラネットトラフィックと非エクストラネットトラフィックの両方に包括的PトンネルをアドバタイズするADルート。この場合、包括的Pトンネルは使用されません。
This section applies when inter-site shared trees are used, as specified in Section 13 of [RFC6514].
このセクションは、[RFC6514]のセクション13で指定されている、サイト間共有ツリーが使用されている場合に適用されます。
If VRF-S exports a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI and VRF-S also exports a UMH-eligible route matching C-S, the Source Active A-D route MUST carry at least one RT in common with the UMH-eligible route. The RT MUST be chosen such that the following condition holds: if a VRF, say VRF-R, contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route.
VRF-SがそのNLRIのMulticast SourceフィールドにCSを含むSource Active ADルートをエクスポートし、VRF-SもCSに一致するUMH適格ルートをエクスポートする場合、Source Active ADルートは、 UMH適格ルート。 RTは、次の条件が満たされるように選択する必要があります。VRF、たとえばVRF-Rに、CSからエクストラネットトラフィックを受信することをポリシーで許可されているエクストラネットCレシーバーが含まれている場合、VRF-RはUMH適格ルートとソースActive ADルート。
By default, a Source Active A-D route for a given (C-S,C-G), exported by a given VRF, carries the same set of RTs as the UMH-eligible route matching C-S that is exported from that VRF.
デフォルトでは、特定のVRFによってエクスポートされた特定の（C-S、C-G）のソースアクティブA-Dルートは、そのVRFからエクスポートされたC-Sに一致するUMH適格ルートと同じセットのRTを伝送します。
This section applies when inter-site shared trees are not used, as specified in Section 14 of [RFC6514].
このセクションは、[RFC6514]のセクション14で指定されているように、サイト間共有ツリーが使用されていない場合に適用されます。
Suppose that a VRF, say VRF-X, contains the C-RP for a given extranet C-group, say C-G. If C-S is an active source for C-G, then, following the procedures of Section 14.1 of [RFC6514], VRF-X may export a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI. With the following text, this document replaces the rule specified in Section 14.1 of [RFC6514] for constructing the RT(s) carried by such a route: VRF-X MUST be configured such that the Source Active A-D route for (C-S,C-G) carries the same set of RTs as the UMH-eligible route matching C-S that is exported from the VRF(s) containing C-S. This way, if a VRF, say VRF-R, contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route.
VRF、たとえばVRF-Xに、特定のエクストラネットCグループ、たとえばC-GのC-RPが含まれているとします。 C-SがC-Gのアクティブソースである場合、[RFC6514]のセクション14.1の手順に従って、VRF-Xは、NLRIの[マルチキャストソース]フィールドにC-Sを含むソースアクティブA-Dルートをエクスポートする場合があります。次のテキストで、このドキュメントは、[RFC6514]のセクション14.1で指定された、このようなルートによって運ばれるRTを構築するためのルールを置き換えます。VRF-Xは、（CS、CG）のソースアクティブADルートになるように構成する必要がありますCSを含むVRFからエクスポートされた、CSに一致するUMH適格ルートと同じRTのセットを伝送します。このように、VRF、たとえばVRF-Rに、ポリシーによってC-Sからのエクストラネットトラフィックの受信を許可されたエクストラネットCレシーバーが含まれている場合、VRF-RはUMH適格ルートとソースアクティブA-Dルートの両方をインポートします。
If a VRF contains both extranet C-sources and non-extranet C-sources, it MUST be configured with both a default RD and an extranet RD (see Section 1.3). The use of these RDs is explained in the following subsections.
VRFにエクストラネットCソースと非エクストラネットCソースの両方が含まれている場合は、デフォルトのRDとエクストラネットRDの両方で構成する必要があります（セクション1.3を参照）。これらのRDの使用については、次のサブセクションで説明します。
This section applies when VRF-S is using extranet separation AND when VRF-S is using an inclusive P-tunnel to carry some or all of the extranet C-flows that it needs to transmit to other VRFs.
このセクションは、VRF-Sがエクストラネット分離を使用している場合、およびVRF-Sが他のVRFに送信する必要があるエクストラネットCフローの一部またはすべてを運ぶために包括的なPトンネルを使用している場合に適用されます。
If VRF-S contains both extranet C-sources and non-extranet C-sources, and inclusive P-tunnels are used to carry both extranet C-flows and non-extranet C-flows, then there MUST be two Inclusive Tunnels from VRF-S, one of which is to be used only to carry extranet C-flows (the "extranet inclusive P-tunnel") and one of which is to be used only to carry non-extranet C-flows (the "non-extranet inclusive P-tunnel").
VRF-SにエクストラネットCソースと非エクストラネットCソースの両方が含まれ、包括的Pトンネルを使用してエクストラネットCフローと非エクストラネットCフローの両方を伝送する場合、VRF-からの2つの包括的トンネルが存在する必要があります。 S、その1つはエクストラネットCフロー（「エクストラネットを含むPトンネル」）を運ぶためにのみ使用され、もう1つは非エクストラネットCフロー（「非エクストラネットを含む」 Pトンネル」）。
In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. Their respective NLRIs MUST of course have different RDs. One of the Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel in its PTA. This route MUST have the VRF's extranet RD in its NLRI. The other route identifies the non-extranet inclusive P-tunnel in its PTA. This route MUST have the VRF's default RD in its PTA.
この場合、VRFは2つのIntra-AS I-PMSI A-Dルートを発信する必要があります。もちろん、それぞれのNLRIは異なるRDを持つ必要があります。 Intra-AS I-PMSI A-Dルートの1つは、PTAでエクストラネットを含むPトンネルを識別します。このルートには、NLRIにVRFのエクストラネットRDが含まれている必要があります。もう1つのルートは、PTAで非エクストラネットの包括的Pトンネルを識別します。このルートには、PTAにVRFのデフォルトRDが含まれている必要があります。
If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but does not use an inclusive P-tunnel for carrying non-extranet traffic, then of course only a single Intra-AS I-PMSI A-D route need be originated. The PTA of this route identifies the "extranet inclusive P-tunnel". The NLRI of that route MUST contain the VRF's extranet RD.
VRF-Sがエクストラネットトラフィックの伝送に包括的Pトンネルを使用し、非エクストラネットトラフィックの伝送に包括的Pトンネルを使用しない場合、当然、1つのIntra-AS I-PMSI A-Dルートのみを発信する必要があります。このルートのPTAは、「エクストラネットを含むPトンネル」を識別します。そのルートのNLRIには、VRFのエクストラネットRDが含まれている必要があります。
An Intra-AS I-PMSI A-D route whose PTA identifies an extranet inclusive P-tunnel MUST carry the Extranet Separation Extended Community defined in Section 4.5.
PTAがエクストラネットを含むPトンネルを識別するIntra-AS I-PMSI A-Dルートは、セクション4.5で定義されたエクストラネット分離拡張コミュニティを運ぶ必要があります。
The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies the "extranet inclusive P-tunnel" MUST be chosen such that the following condition holds: if a VRF (call it "VRF-R") imports a UMH-eligible route from VRF-S and that route matches an extranet C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route.
PTAが「エクストラネットを含むPトンネル」を識別するIntra-AS I-PMSI ADルートによって運ばれるRTは、次の条件が満たされるように選択する必要があります：VRF（「VRF-R」と呼ぶ）がUMHをインポートする場合VRF-Sからの適格なルートとそのルートがエクストラネットCソースと一致する場合、VRF-RはそのIntra-AS I-PMSI ADルートもインポートします。
Note that when extranet separation is used, it is possible to use an inclusive P-tunnel for non-extranet traffic while using only selective P-tunnels for extranet traffic. It is also possible to use an inclusive P-tunnel for extranet traffic while using only selective P-tunnels for non-extranet traffic.
エクストラネット分離を使用する場合、エクストラネットトラフィックには選択的Pトンネルのみを使用しながら、非エクストラネットトラフィックには包括的Pトンネルを使用できることに注意してください。エクストラネットトラフィックには包括的Pトンネルを使用し、非エクストラネットトラフィックには選択的Pトンネルのみを使用することもできます。
Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose that R-SP is used to bind some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Let R-UMH be a UMH-eligible route that is exported from VRF-S and matches the given extranet C-source. In that case, R-SP and R-UMH MUST have at least one RT in common. Further, the RTs carried by these two routes MUST be such that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625].
R-SPを、VRF-SからエクスポートされるS-PMSI A-Dルートとします。 R-SPを使用して、特定のエクストラネットCソースから特定の選択的PトンネルにエクストラネットCフローの一部またはすべてをバインドするとします。 R-UMHを、VRF-Sからエクスポートされ、指定されたエクストラネットCソースに一致するUMH適格ルートとします。その場合、R-SPとR-UMHは少なくとも1つのRTを共有する必要があります。さらに、これらの2つのルートによって運ばれるRTは、R-UMHをインポートするすべてのVRFがR-SPもインポートするようなものである必要があります。これらのルールは、R-SPがワイルドカードを使用するかどうかに関係なく適用されます[RFC6625]。
The following rules, specific to the use of extranet separation, apply:
エクストラネット分離の使用に固有の次のルールが適用されます。
o A selective P-tunnel MUST NOT carry C-flows from both extranet and non-extranet C-sources.
o 選択的Pトンネルは、エクストラネットと非エクストラネットの両方のCソースからのCフローを伝送してはなりません（MUST NOT）。
o If it is desired to use a (C-*,C-*) S-PMSI to carry extranet traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. These two routes MUST have different RDs in their respective NLRI fields, and their respective PTAs MUST identify different P-tunnels. If the route advertises a P-tunnel that carries only non-extranet traffic, the route's NLRI MUST contain the VRF's default RD. If the route advertises a P-tunnel that carries only extranet traffic, the route's NLRI MUST contain the VRF's extranet RD.
o （C-*、C- *）S-PMSIを使用してエクストラネットトラフィックを伝送し、（C-*、C- *）S-PMSIを使用して非エクストラネットトラフィックを伝送する場合は、2つの（C -*、C- *）S-PMSI ADルートを発信する必要があります。これらの2つのルートは、それぞれのNLRIフィールドに異なるRDがなければならず、それぞれのPTAは異なるPトンネルを識別しなければなりません（MUST）。ルートが非エクストラネットトラフィックのみを伝送するPトンネルをアドバタイズする場合、ルートのNLRIにはVRFのデフォルトRDが含まれている必要があります。ルートがエクストラネットトラフィックのみを伝送するPトンネルをアドバタイズする場合、ルートのNLRIにはVRFのエクストラネットRDが含まれている必要があります。
o In the following cases, an S-PMSI A-D route exported from the VRF MUST have the VRF's extranet RD in its NLRI:
o 次の場合、VRFからエクスポートされたS-PMSI A-Dルートには、NLRIにVRFのエクストラネットRDが含まれている必要があります。
* The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D route, and C-S is an extranet C-source.
* S-PMSI A-Dルートは（C-S、C-G）または（C-S、C- *）S-PMSI A-Dルートであり、C-SはエクストラネットCソースです。
* The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G is an extranet C-group.
* S-PMSI A-Dルートは（C-*、C-G）S-PMSI A-Dルートであり、C-GはエクストラネットCグループです。
In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI A-D route MUST have the VRF's default RD in its NLRI.
それ以外の場合はすべて、（C-S、C-G）、（C-S、C- *）、または（C-*、C-G）S-PMSI A-DルートのNLRIにVRFのデフォルトRDが必要です。
o A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used to carry extranet traffic MUST carry the Extranet Separation Extended Community defined in Section 4.5.
o エクストラネットトラフィックの伝送に使用されるPトンネルをアドバタイズする（C-*、C- *）S-PMSI A-Dルートは、セクション4.5で定義されたエクストラネット分離拡張コミュニティを伝送する必要があります。
An implementation MUST allow the set of RTs carried by the S-PMSI A-D routes to be specified by configuration. In the absence of such configuration, an S-PMSI A-D route originated by a given VRF, say VRF-X, MUST carry a default set of RTs, as specified by the following rules:
実装は、S-PMSI A-Dルートによって運ばれるRTのセットが構成によって指定されることを許可しなければなりません（MUST）。そのような構成がない場合、特定のVRF、たとえばVRF-Xから発信されたS-PMSI A-Dルートは、次のルールで指定されているように、デフォルトのRTセットを運ぶ必要があります。
1. Rule 1 of Section 7.2.2 applies.
1. セクション7.2.2のルール1が適用されます。
2. By default, if C-G is an extranet C-group, rule 2 of Section 7.2.2 applies.
2. デフォルトでは、C-GがエクストラネットCグループである場合、セクション7.2.2のルール2が適用されます。
3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X is to be used for extranet traffic, it carries the same RTs that would be carried (as specified in Section 7.3.1) by an I-PMSI A-D route originated by VRF-X if that I-PMSI A-D route were advertising an inclusive P-tunnel for carrying extranet traffic. In general, a given VRF would not originate both an S-PMSI A-D route advertising a (C-*,C-*) selective P-tunnel for extranet traffic and an I-PMSI A-D route advertising an inclusive P-tunnel for extranet traffic, as the inclusive P-tunnel would not get used in that case.
3.デフォルトでは、VRF-Xから発信された（C-*、C- *）S-PMSI ADルートがエクストラネットトラフィックに使用される場合、（セクション7.3で指定されているように）伝送されるのと同じRTを伝送します。 1）I-PMSI ADルートがエクストラネットトラフィックを伝送するための包括的なPトンネルをアドバタイズしている場合、VRF-Xによって発信されたI-PMSI ADルート。一般に、特定のVRFは、エクストラネットトラフィックの（C-*、C- *）選択的PトンネルをアドバタイズするS-PMSI ADルートと、エクストラネットトラフィックの包括的PトンネルをアドバタイズするI-PMSI ADルートの両方を発信しません。その場合、包括的なPトンネルは使用されないためです。
The procedures of Section 7.2.3 apply.
セクション7.2.3の手順が適用されます。
However, if a Source Active A-D route is exported from a given VRF and the route contains C-S, where C-S is an extranet C-source, then the RD of the route's NLRI MUST be the extranet RD of the VRF. Otherwise, the RD is the default RD of the VRF.
ただし、ソースアクティブA-Dルートが特定のVRFからエクスポートされ、ルートにC-Sが含まれる場合（C-SはエクストラネットCソース）、ルートのNLRIのRDはVRFのエクストラネットRDでなければなりません。それ以外の場合、RDはVRFのデフォルトRDです。
This section applies whether extranet separation is used or not.
このセクションは、エクストラネット分離が使用されているかどうかに関係なく適用されます。
In the context of a VRF with receivers for a particular C-flow, a PE must determine the P-tunnel over which packets of that C-flow are expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D route that "matches" the flow. The matching A-D route will contain a PTA that specifies the P-tunnel being used to carry the traffic of that C-flow. We will refer to this P-tunnel as the "expected P-tunnel" for the C-flow. (Note that, per [MVPN-IR], if the PTA specifies a tunnel of type "Ingress Replication" (IR), the identifier of the P-tunnel is actually the NLRI of the I-PMSI or S-PMSI A-D route. If the PTA specifies a tunnel type other than IR, the identifier of the P-tunnel is found in the Tunnel Identifier field of the PTA.)
特定のCフローのレシーバーを備えたVRFのコンテキストでは、PEは、そのCフローのパケットが到着すると予想されるPトンネルを決定する必要があります。これは、フローに「一致」するI-PMSIまたはS-PMSI A-Dルートを見つけることによって行われます。一致するA-Dルートには、そのCフローのトラフィックの伝送に使用されているPトンネルを指定するPTAが含まれます。このPトンネルをCフローの「予想されるPトンネル」と呼びます。 （[MVPN-IR]に従って、PTAがタイプ「入力レプリケーション」（IR）のトンネルを指定する場合、Pトンネルの識別子は実際にはI-PMSIまたはS-PMSI ADルートのNLRIであることに注意してください。 PTAがIR以外のトンネルタイプを指定する場合、Pトンネルの識別子はPTAのトンネル識別子フィールドにあります。
A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST join the expected P-tunnel for that C-flow, and the PE MUST remain joined to the P-tunnel as long as (1) the PE continues to need to receive the given C-flow and (2) the P-tunnel continues to remain the expected P-tunnel for that C-flow. Procedures for joining and leaving a tunnel depend, of course, on the tunnel type.
特定の（CS、CG）または（C-*、CG）Cフローを受信する必要があるPEは、そのCフローの予想されるPトンネルに参加する必要があり、PEはPトンネルに参加したままである必要があります（1）PEは引き続き所定のCフローを受信する必要があり、（2）Pトンネルは引き続きそのCフローで予期されるPトンネルのままです。トンネルへの参加とトンネルからの脱退の手順は、もちろん、トンネルのタイプによって異なります。
If a PTA specifies a non-zero MPLS label for a tunnel that is not an IR tunnel, then the PE originating the A-D route containing that PTA is advertising an aggregate P-tunnel. The aggregate P-tunnel can be thought of as an outer P-tunnel multiplexing some number of inner P-tunnels. The inner P-tunnels are demultiplexed by means of the MPLS label in the PTA. In this document, when we talk of the "expected P-tunnel" in the context of an aggregate P-tunnel, we refer to a particular inner P-tunnel, not to the outer P-tunnel. It is this "inner P-tunnel" that is the expected P-tunnel for a given C-flow.
PTAがIRトンネルではないトンネルにゼロ以外のMPLSラベルを指定する場合、そのPTAを含むA-Dルートを発信するPEは、集約Pトンネルをアドバタイズしています。集約Pトンネルは、いくつかの内部Pトンネルを多重化する外部Pトンネルと考えることができます。内部Pトンネルは、PTAのMPLSラベルによって逆多重化されます。このドキュメントでは、集約Pトンネルのコンテキストで「予想されるPトンネル」について説明する場合、外部Pトンネルではなく、特定の内部Pトンネルを指します。特定のCフローで予想されるPトンネルは、この「内部Pトンネル」です。
In order to find the expected P-tunnel for a given C-flow, the upstream PE of the C-flow is first determined. Then, the S-PMSI A-D routes originated by that PE are examined, and their NLRIs compared to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for reception". (If there is no S-PMSI A-D route that matches a given C-flow, the expected P-tunnel for that C-flow may have been advertised in an I-PMSI A-D route; see Section 7.4.5.)
特定のCフローの予想されるPトンネルを見つけるために、Cフローの上流PEが最初に決定されます。次に、そのPEから発信されたS-PMSI A-Dルートが検査され、それらのNLRIがフローの（C-S / C-RP、C-G）と比較されて、「受信の一致」があるかどうかが確認されます。 （特定のCフローと一致するS-PMSI A-Dルートがない場合、そのCフローの予想されるPトンネルはI-PMSI A-Dルートでアドバタイズされている可能性があります。セクション7.4.5を参照してください。）
The rules for determining, in non-extranet cases, whether a given C-flow is a "match for reception" for a given S-PMSI A-D route are given in Section 3.2 of [RFC6625]. Note that we use the terms "installed" and "originated" as they are defined in Section 3.2 of [RFC6625]. (See also Section 1.1 of this document.)
非エクストラネットの場合に、特定のCフローが特定のS-PMSI A-Dルートの「受信の一致」であるかどうかを決定するためのルールは、[RFC6625]のセクション3.2に記載されています。 [インストール済み]と[元の]という用語は、[RFC6625]のセクション3.2で定義されているとおりに使用することに注意してください。 （このドキュメントのセクション1.1も参照してください。）
This specification provides additional rules for determining whether a given S-PMSI A-D route is a "match for reception" for a given (C-S/C-RP,C-G). Note that these rules all assume the context of a particular VRF into which the A-D route has been imported.
この仕様は、特定のS-PMSI A-Dルートが特定の（C-S / C-RP、C-G）の「受信の一致」であるかどうかを決定するための追加ルールを提供します。これらのルールはすべて、A-Dルートがインポートされた特定のVRFのコンテキストを想定していることに注意してください。
The rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for transmission" remain unchanged.
[RFC6625]で規定されているS-PMSI A-Dルートが「送信用の一致」であるかどうかを決定するためのルールは変更されていません。
Suppose that a PE has originated a C-multicast Shared Tree Join for (C-*,C-G) but has not originated a C-multicast Source Tree Join for (C-S,C-G). Suppose also that the PE has received and installed a Source Active A-D route for (C-S,C-G). As described in Section 13.2 of [RFC6514], the PE must receive the (C-S,C-G) traffic from the tunnel the originator of the installed Source Active A-D route uses for sending (C-S,C-G).
PEが（C-*、C-G）のCマルチキャスト共有ツリー結合を開始したが、（C-S、C-G）のCマルチキャストソースツリー結合を開始していないとします。また、PEが（C-S、C-G）のソースアクティブA-Dルートを受信してインストールしたとします。 [RFC6514]のセクション13.2で説明されているように、PEは、インストールされているソースアクティブA-Dルートの発信者が（C-S、C-G）の送信に使用するトンネルから（C-S、C-G）トラフィックを受信する必要があります。
The originator of the installed Source Active A-D route is determined as follows:
インストールされているソースアクティブA-Dルートの発信元は、次のように決定されます。
1. Look at the "UMH Route Candidate Set" for C-S, as defined in Section 5.1.3 of [RFC6513].
1. [RFC6513]のセクション5.1.3で定義されている、C-Sの「UMHルート候補セット」を確認します。
2. From that set, select a subset of UMH routes to C-S, such that each route in the subset has at least one RT in common with the Source Active A-D route and at least one of the RTs in common is an import RT of the VRF.
2. そのセットから、C-SへのUMHルートのサブセットを選択します。サブセット内の各ルートには、ソースアクティブA-Dルートと共通のRTが少なくとも1つあり、共通のRTの少なくとも1つはVRFのインポートRTです。
3. From that subset, find the route whose RD is the same as the RD from the NLRI of the Source Active A-D route.
3. そのサブセットから、RDがソースアクティブA-DルートのNLRIからのRDと同じルートを見つけます。
4. The upstream PE is the PE identified in the VRF Route Import Extended Community of that route.
4. アップストリームPEは、そのルートのVRFルートインポート拡張コミュニティで識別されたPEです。
5. The upstream AS is the AS identified in the Source AS Extended Community of that route.
5. アップストリームASは、そのルートのソースAS拡張コミュニティで識別されたASです。
If step 2 results in an empty set or step 3 fails to find a route, then the upstream PE of the Source Active A-D route cannot be determined, and it is necessary to act as if the Source Active A-D route had not been installed. (A subsequent change to the UMH Route Candidate Set for C-S may require that a new attempt be made to determine the upstream PE.)
手順2の結果が空のセットになった場合、または手順3でルートが見つからなかった場合、ソースアクティブA-Dルートの上流PEを特定できず、ソースアクティブA-Dルートがインストールされていないかのように動作する必要があります。 （C-SのUMHルート候補セットに対するその後の変更では、アップストリームPEを決定するために新しい試みを行う必要がある場合があります。）
Once the upstream PE is determined, the P-tunnel over which the flow is expected is determined according to the procedures already described in this section.
アップストリームPEが決定されると、このセクションですでに説明した手順に従って、フローが予想されるPトンネルが決定されます。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-S,C-G) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) unless one of the following conditions holds (in addition to the conditions specified in [RFC6625]):
エクストラネット機能が提供されている場合、NLRIに（CS、CG）が含まれるS-PMSI ADルートは、次の条件のいずれかが満たされない限り、特定のCフロー（CS、CG）の「受信の一致」とは見なされません。 （[RFC6625]で指定された条件に加えて）：
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
o 「（C-S、C-G）または（C-S、C- *）Pトンネルごとに単一のCソース」がプロビジョニングされている、または
o the selected UMH route for C-S has at least one RT in common with the S-PMSI A-D route, and at least one of the common RTs is an import RT of the VRF.
o C-S用に選択されたUMHルートには、S-PMSI A-Dルートと共通の少なくとも1つのRTがあり、少なくとも1つの共通RTはVRFのインポートRTです。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-S,C-*) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) unless one of the following conditions holds (in addition to the conditions specified in [RFC6625]):
エクストラネット機能が提供されている場合、NLRIに（CS、C- *）が含まれるS-PMSI ADルートは、次のいずれかでない限り、特定のCフロー（CS、CG）の「受信の一致」とは見なされません。条件が保持されます（[RFC6625]で指定された条件に加えて）：
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
o 「（C-S、C-G）または（C-S、C- *）Pトンネルごとに単一のCソース」がプロビジョニングされている、または
o the selected UMH route for C-S has at least one RT in common with the S-PMSI A-D route, and at least one of the common RTs is an import RT of the VRF.
o C-S用に選択されたUMHルートには、S-PMSI A-Dルートと共通の少なくとも1つのRTがあり、少なくとも1つの共通RTはVRFのインポートRTです。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-*,C-G) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) in a given VRF unless either condition 1 or condition 2 below holds (in addition to the conditions specified in [RFC6625]):
エクストラネット機能が提供されている場合、NLRIに（C-*、CG）が含まれるS-PMSI ADルートは、特定のVRFの特定のCフロー（CS、CG）の「受信の一致」とは見なされません以下の条件1または条件2のいずれかが成り立つ（[RFC6625]で指定された条件に加えて）：
1. The given VRF has currently originated a C-multicast Shared Tree Join route for (C-*,C-G), and
1. 指定されたVRFは、現在（C-*、C-G）のCマルチキャスト共有ツリー参加ルートを発信しています。
a. (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route (according to [RFC6625]) in the given VRF, and
a. （C-*、C-G）は、指定されたVRFにインストールされた（C-*、C-G）S-PMSI A-Dルート（[RFC6625]に従って）に一致します。
b. either
b. どちらか
i. the "single C-group per (C-*,C-G) P-tunnel" policy has been provisioned, or
i. 「（C-*、C-G）Pトンネルごとの単一のCグループ」ポリシーがプロビジョニングされている、または
ii. the RTs of that S-PMSI A-D route form a non-empty intersection with the RTs carried in the VRF's selected UMH route for C-RP of that C-G, or
ii。そのS-PMSI A-DルートのRTは、そのC-GのC-RPのVRFの選択されたUMHルートで運ばれるRTと空でない交差を形成します。
iii. installed in the VRF is at least one (C-S,C-G) Source Active A-D route that was originated by the same PE as the (C-*,C-G) S-PMSI A-D route.
iii。 VRFにインストールされているのは、（C-*、C-G）S-PMSI A-Dルートと同じPEによって発信された少なくとも1つの（C-S、C-G）ソースアクティブA-Dルートです。
2. The given VRF does not have a currently originated C-multicast Shared Tree Join for (C-*,C-G), but
2. 指定されたVRFには、（C-*、C-G）の現在生成されたCマルチキャスト共有ツリー結合がありませんが、
a. there are one or more values for C-S for which the VRF has a currently originated Source Tree Join C-multicast route for (C-S,C-G), and
a. VRFが（C-S、C-G）の現在発信されたソースツリー結合Cマルチキャストルートを持つC-Sの値が1つ以上あります。
b. the (C-* C-G) S-PMSI A-D route matches (according to [RFC6625]) each such (C-S,C-G), and
b. （C- * C-G）S-PMSI A-Dルートが一致する（[RFC6625]に従って）そのような（C-S、C-G）、および
c. either
c. どちらか
i. the "single C-group per (C-*,C-G) P-tunnel" policy has been provisioned, or
i. 「（C-*、C-G）Pトンネルごとの単一のCグループ」ポリシーがプロビジョニングされている、または
ii. the RTs of that S-PMSI A-D route form a non-empty intersection with the RTs carried in the VRF's selected UMH routes for each such C-S
ii。そのS-PMSI A-DルートのRTは、そのような各C-SのVRFの選択されたUMHルートで運ばれるRTと空でない交差を形成します
If a VRF has an installed (C-*,C-G) S-PMSI A-D route but does not have a (C-S,C-G) or (C-*,C-G) multicast state that matches that route for reception, the procedures of Section 12.3 ("Receiving S-PMSI A-D Routes by PEs") of [RFC6514] are not invoked for that route. If those multicast states are created at some later time when the route is still installed, the procedures of Section 12.3 of [RFC6514] are invoked at that time.
VRFに（C-*、CG）S-PMSI ADルートがインストールされているが、受信のためにそのルートと一致する（CS、CG）または（C-*、CG）マルチキャストステートがない場合、セクション12.3の手順[RFC6514]の（「PEによるS-PMSI ADルートの受信」）は、そのルートに対して呼び出されません。ルートがまだインストールされているときにこれらのマルチキャストステートが作成されると、その時点で[RFC6514]のセクション12.3の手順が呼び出されます。
A (C-*,C-*) S-PMSI A-D route (call it "R-AD") is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) or (C-*,C-G) unless the following conditions hold (in addition to the conditions specified in [RFC6625]):
（C-*、C- *）S-PMSI ADルート（「R-AD」と呼ぶ）は、特定のCフロー（CS、CG）または（C- *、CG）以下の条件が満たされない限り（[RFC6625]で指定された条件に加えて）：
o The selected UMH route (call it "R-UMH") for C-S or for C-G's C-RP, respectively, has at least one RT in common with R-AD, and at least one of the common RTs is an import RT of the VRF.
o CSまたはCGのC-RPに対してそれぞれ選択されたUMHルート（「R-UMH」と呼ぶ）には、R-ADと共通のRTが少なくとも1つあり、共通のRTの少なくとも1つはインポートRTです。 VRFの。
o Either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o R-ADとR-UMHの両方がエクストラネット分離拡張コミュニティを運ぶか、どちらもエクストラネット分離拡張コミュニティを運ばない。
If a particular egress VRF in a particular egress PE contains no matching S-PMSI A-D routes for a particular C-flow, then the C-flow is expected to arrive (at that egress VRF) on an inclusive P-tunnel.
特定の出力PEの特定の出力VRFに、特定のCフローの一致するS-PMSI A-Dルートが含まれていない場合、Cフローは包括的なPトンネルに（その出力VRFに）到着することが期待されます。
Suppose that an egress PE has originated a (C-S,C-G) C-multicast Source Tree Join. Let R-UMH be the selected UMH route (in the given egress VRF) for C-S. As specified in [RFC6514], the selected upstream PE for (C-S,C-G) is determined from the VRF Route Import Extended Community of R-UMH, and the "selected upstream AS" for the flow is determined from the Source AS Extended Community of R-UMH.
出力PEが（C-S、C-G）Cマルチキャストソースツリー結合を開始したとします。 R-UMHを（指定された出力VRFの）C-Sの選択されたUMHルートとします。 [RFC6514]で指定されているように、（CS、CG）の選択されたアップストリームPEは、R-UMHのVRFルートインポート拡張コミュニティから決定され、フローの「選択されたアップストリームAS」は、 R-UMH。
Suppose that an egress PE has originated a (C-*,C-G) C-multicast Shared Tree Join but has not originated a (C-S,C-G) C-multicast Source Tree Join. If the egress VRF does not have a (C-S,C-G) Source Active A-D route installed, the selected upstream PE is determined from the VRF Route Import Extended Community of the installed UMH-eligible route matching C-RP, where C-RP is the RP for the group C-G. The selected upstream AS for the flow is determined from the Source AS Extended Community of that route. If the egress VRF does have a (C-S,C-G) Source Active A-D route installed, the selected upstream PE and upstream AS are determined as specified in Section 7.4. In either case, let R-UMH be the installed UMH-eligible route matching C-S.
出力PEが（C-*、C-G）Cマルチキャスト共有ツリー結合を開始したが、（C-S、C-G）Cマルチキャストソースツリー結合を開始していないとします。出力VRFに（CS、CG）ソースアクティブADルートがインストールされていない場合、選択されたアップストリームPEは、インストールされたUMH適格ルートのC-RPに一致するVRFルートインポート拡張コミュニティから決定されます。グループCGのRP。フローに選択されたアップストリームASは、そのルートのソースAS拡張コミュニティから決定されます。出力VRFに（C-S、C-G）ソースアクティブA-Dルートがインストールされている場合、選択されたアップストリームPEおよびアップストリームASは、セクション7.4で指定されているように決定されます。どちらの場合も、R-UMHをC-Sに一致するインストール済みのUMH適格ルートとします。
The inclusive P-tunnel that is expected to be carrying a particular C-flow is found as follows:
特定のCフローを伝送すると予想される包括的なPトンネルは、次のように見つかります。
o If the selected upstream AS is the local AS or segmented Inter-AS P-tunnels are not being used to instantiate I-PMSIs, then look in the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such that (a) R-AD is originated by the selected upstream PE, (b) R-AD has at least one RT in common with R-UMH, (c) at least one of the common RTs is an import RT of the local VRF, and (d) either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o 選択されたアップストリームASがローカルASであるか、セグメント化されたInter-AS PトンネルがI-PMSIのインスタンス化に使用されていない場合、インストールされているIntra-AS I-PMSI ADルート、R-ADをVRFで調べます。 （a）R-ADは選択されたアップストリームPEから発信され、（b）R-ADはR-UMHと共通の少なくとも1つのRTを持っています、（c）少なくとも1つの共通RTはローカルVRFのインポートRTです、および（d）R-ADとR-UMHの両方がエクストラネット分離拡張コミュニティを運ぶか、どちらもエクストラネット分離拡張コミュニティを運ばない。
The PTA of R-AD specifies the P-tunnel over which the traffic of the given C-flow is expected.
R-ADのPTAは、特定のCフローのトラフィックが予想されるPトンネルを指定します。
o If the selected upstream AS is not the local AS and segmented Inter-AS P-tunnels are being used to instantiate I-PMSIs, then look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD, such that (a) the Source AS field of R-AD's NLRI contains the AS number of the selected upstream AS, (b) R-AD has at least one RT in common with R-UMH, (c) at least one of the common RTs is an import RT of the local VRF, and (d) either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o 選択されたアップストリームASがローカルASではなく、セグメント化されたInter-AS PトンネルがI-PMSIのインスタンス化に使用されている場合、インストールされているInter-AS I-PMSI ADルート、R-ADをVRFで調べます。 （a）R-ADのNLRIのソースASフィールドには、選択された上流ASのAS番号が含まれます。（b）R-ADには、R-UMHと共通のRTが少なくとも1つあります。（c）共通RTの少なくとも1つローカルVRFのインポートRTであり、（d）R-ADとR-UMHの両方がエクストラネット分離拡張コミュニティを運ぶか、どちらもエクストラネット分離拡張コミュニティを運ばない。
The PTA of R-AD specifies the P-tunnel over which the traffic of the given C-flow is expected.
R-ADのPTAは、特定のCフローのトラフィックが予想されるPトンネルを指定します。
Any packets that arrive on a P-tunnel other than the expected P-tunnel (as defined in Section 7.4) MUST be discarded unless it is known that all the packets carried by both P-tunnels are from the same ingress VRF. (See Section 2.3.1 for a more detailed discussion of when to discard packets from other than the expected P-tunnel.) Note that packets arriving on the wrong P-tunnel are to be discarded even if they are arriving from the expected PE.
予想されるPトンネル（セクション7.4で定義）以外のPトンネルに到着するパケットは、両方のPトンネルによって運ばれるすべてのパケットが同じ入力VRFからのものであることがわかっていない限り、破棄する必要があります。 （予想されるPトンネル以外からのパケットを破棄するタイミングの詳細については、セクション2.3.1を参照してください。）間違ったPトンネルに到達するパケットは、予想されるPEから到達していても破棄されることに注意してください。
When multiple VRFs that contain extranet receivers for a given extranet source are present on the same PE, this PE becomes a single leaf of the P-tunnel used for sending (multicast) traffic from that source to these extranet receivers. The PE MUST be able to replicate this traffic to the multiple VRFs. Specific procedures for doing so are local to the PE and are outside the scope of this document.
特定のエクストラネットソースのエクストラネットレシーバーを含む複数のVRFが同じPEに存在する場合、このPEは、そのソースからこれらのエクストラネットレシーバーへのトラフィックの送信（マルチキャスト）に使用されるPトンネルの単一リーフになります。 PEは、このトラフィックを複数のVRFに複製できる必要があります。そうするための特定の手順は、PEにローカルであり、このドキュメントの範囲外です。
Two or more VRFs on the same PE may import the same S-PMSI A-D route. If this S-PMSI A-D route contains a PTA that has its "Leaf Information Required" flag set, it may be necessary for the PE to originate a Leaf A-D route whose NLRI is computed from the NLRI of the S-PMSI A-D route. (Details are provided in [RFC6514].) Note that for a given S-PMSI A-D route, the PE can originate only one corresponding Leaf A-D route, even if the S-PMSI A-D route is imported into multiple VRFs. This Leaf A-D route can thus be thought of as originating from several VRFs. It MUST NOT be withdrawn by the PE until there are no longer any VRFs originating it.
同じPE上の2つ以上のVRFが同じS-PMSI A-Dルートをインポートする場合があります。このS-PMSI A-Dルートに「Leaf Information Required」フラグセットが設定されたPTAが含まれている場合、PEが、NLRIがS-PMSI A-DルートのNLRIから計算されるLeaf A-Dルートを発信する必要がある場合があります。 （詳細は[RFC6514]で提供されています。）S-PMSI A-Dルートが複数のVRFにインポートされている場合でも、特定のS-PMSI A-Dルートの場合、PEは対応する1つのリーフA-Dルートのみを発信できます。したがって、このリーフA-Dルートは、いくつかのVRFから発信されたものと考えることができます。元のVRFがなくなるまで、PEによって撤回してはなりません。
[RFC6514] specifies conditions under which a PE originates a C-multicast Source Tree Join or a C-multicast Shared Tree Join, based on the (*,G) and (S,G) states associated with a given VRF. It also specifies the procedure for computing the NLRI of each such route. While a given PE may contain two or more VRFs that have (extranet) receivers for the same extranet C-flow, the PE cannot originate more than one BGP route with a given NLRI. If there are multiple VRFs, each of which has state that is sufficient to cause a given C-multicast route to be originated, the route can be thought of as originating from several VRFs. It MUST NOT be withdrawn by the PE until there is no longer any VRF with multicast state sufficient to cause the route to be originated.
[RFC6514]は、特定のVRFに関連付けられた（*、G）および（S、G）状態に基づいて、PEがCマルチキャストソースツリー結合またはCマルチキャスト共有ツリー結合を開始する条件を指定します。また、そのような各ルートのNLRIを計算する手順も指定します。特定のPEには、同じエクストラネットCフローの（エクストラネット）レシーバーを持つ2つ以上のVRFが含まれている場合がありますが、PEは特定のNLRIで複数のBGPルートを発信することはできません。複数のVRFがあり、それぞれに特定のCマルチキャストルートを発信するのに十分な状態がある場合、ルートは複数のVRFから発信されていると考えることができます。ルートを発生させるのに十分なマルチキャスト状態のVRFがなくなるまで、PEによって撤回してはなりません（MUST NOT）。
For a given extranet, the site(s) that contains the extranet source(s) and the site(s) that contains the extranet receiver(s) may be connected to the same PE. In this scenario, the procedures by which (multicast) traffic from these sources is delivered to these receivers are local to the PE and are outside the scope of this document.
特定のエクストラネットについて、エクストラネットソースを含むサイトとエクストラネットレシーバーを含むサイトを同じPEに接続できます。このシナリオでは、これらのソースからの（マルチキャスト）トラフィックがこれらのレシーバーに配信される手順は、PEに対してローカルであり、このドキュメントの範囲外です。
An implementation MUST support multiple extranet VRFs on a PE.
実装は、PE上の複数のエクストラネットVRFをサポートする必要があります。
IANA has allocated two new codepoints from the "First Come First Served" [RFC5226] range of the "Transitive Opaque Extended Community Sub-Types" registry (under the top-level registry "Border Gateway Protocol (BGP) Extended Communities" registry).
IANAは、「先着順」[RFC5226]範囲の「推移的不透明な拡張コミュニティサブタイプ」レジストリ（トップレベルのレジストリ「境界ゲートウェイプロトコル（BGP）拡張コミュニティ」レジストリの下）から2つの新しいコードポイントを割り当てました。
o Extranet Source Extended Community (0x04)
o エクストラネットソース拡張コミュニティ（0x04）
o Extranet Separation Extended Community (0x05)
o エクストラネット分離拡張コミュニティ（0x05）
The security considerations of [RFC6513] and [RFC6514] are applicable.
[RFC6513]および[RFC6514]のセキュリティに関する考慮事項が適用されます。
As is the case with any application of technology based upon [RFC4364], misconfiguration of the RTs may result in VPN security violations (i.e., may result in a packet being delivered to a VPN where, according to policy, it is not supposed to go).
[RFC4364]に基づくテクノロジーのアプリケーションの場合と同様に、RTの設定ミスにより、VPNセキュリティ違反が発生する可能性があります（つまり、ポリシーに従って、パケットがVPNに配信され、 ）。
In those cases where the set of extranet sources of a particular VRF are manually configured, improper configuration of the VRF can result in VPN security violations -- traffic from a host that is not an extranet source may be treated as if it were traffic from an extranet source.
特定のVRFのエクストラネットソースのセットが手動で構成されている場合、VRFの不適切な構成により、VPNセキュリティ違反が発生する可能性があります。エクストラネットソースではないホストからのトラフィックは、エクストラネットソース。
Section 4.4 specifies the optional use of a new Extended Community -- the Extranet Source Extended Community. Security considerations regarding the use and distribution of that Extended Community are discussed in that section.
セクション4.4では、新しい拡張コミュニティ-エクストラネットソース拡張コミュニティのオプションの使用を指定しています。その拡張コミュニティの使用と配布に関するセキュリティの考慮事項については、そのセクションで説明します。
The procedures of this document do not provide encryption of the data flows that are sent across the SP backbone network. Hence, these procedures do not by themselves ensure the privacy or integrity of the data against attacks on the backbone network.
このドキュメントの手順では、SPバックボーンネットワークを介して送信されるデータフローの暗号化は提供していません。したがって、これらの手順だけでは、バックボーンネットワークへの攻撃に対するデータのプライバシーや整合性は保証されません。
In general, different VPNs are allowed to have overlapping IP address spaces; i.e., a host in one VPN may have the same IP address as a host in another. This is safe because the customer routes from a given VPN do not pass into other VPNs. Even if there are overlapping address spaces among VPNs, the routes that are known at any given VPN site are unambiguous, as long as the address space of that VPN is unambiguous. However, this is not necessarily true when extranet service is provided. If an extranet C-receiver in VPN-R is to be able to receive multicast traffic from an extranet C-source in VPN-S, then the address of the VPN-S extranet C-source must be imported into one or more VPN-R VRFs. If that address is also the address of a VPN-R non-extranet C-source, then a system attempting to receive an extranet C-flow from the VPN-R extranet C-source may instead receive a non-extranet C-flow from the VPN-S C-source. Otherwise, a VPN security violation may result.
一般に、異なるVPNはIPアドレススペースの重複を許可されています。つまり、あるVPN内のホストは、別のVPN内のホストと同じIPアドレスを持っている可能性があります。特定のVPNからのカスタマールートが他のVPNに渡らないため、これは安全です。 VPN間でアドレススペースが重複している場合でも、VPNのアドレススペースが明確である限り、特定のVPNサイトで既知のルートは明確です。ただし、エクストラネットサービスが提供されている場合、これは必ずしも当てはまりません。 VPN-RのエクストラネットCレシーバーがVPN-SのエクストラネットCソースからマルチキャストトラフィックを受信できるようにする場合は、VPN-SエクストラネットCソースのアドレスを1つ以上のVPNにインポートする必要があります。 R VRF。そのアドレスがVPN-R非エクストラネットCソースのアドレスでもある場合、VPN-RエクストラネットCソースからエクストラネットCフローを受信しようとするシステムは、代わりに非エクストラネットCフローを受信する可能性があります。 VPN-S Cソース。そうしないと、VPNセキュリティ違反が発生する可能性があります。
That is, when provisioning an extranet between two VPNs that have overlapping address spaces, one must ensure that the IP addresses of the extranet sources and the extranet receivers are not from the overlapping part of the address space. This document specifies that if a route is imported into a given VRF, all addresses that match that route must be unambiguous in the context of that VRF. Improper provisioning of the extranet source addresses or improper provisioning of the RTs may cause this rule to be violated and may result in a VPN security violation.
つまり、重複するアドレススペースを持つ2つのVPN間でエクストラネットをプロビジョニングする場合、エクストラネットソースとエクストラネットレシーバーのIPアドレスがアドレススペースの重複部分からのものでないことを確認する必要があります。このドキュメントでは、ルートが特定のVRFにインポートされる場合、そのルートに一致するすべてのアドレスは、そのVRFのコンテキストで明確でなければならないことを指定しています。エクストラネットの送信元アドレスのプロビジョニングが不適切であるか、RTのプロビジョニングが不適切であると、このルールに違反し、VPNセキュリティ違反が発生する可能性があります。
It is possible that a given multicast C-source is the source of multiple flows, some of which are intended to be extranet C-flows and some of which are intended to be non-extranet flows. However, the procedures of this document will allow any C-receiver that is able to receive the extranet C-flows from a given C-source to also receive the non-extranet C-flows from that source. As a result, VPN security violations may result if any system is a C-source for both extranet and non-extranet C-flows. However, the set of C-flows transmitted by a given C-source is not under the control of the SP. SPs who offer the extranet MVPN service must make sure that this potential for VPN security violations is clearly understood by the customers who administer the C-sources.
特定のマルチキャストCソースが複数のフローのソースである可能性があります。その一部はエクストラネットCフローであり、一部は非エクストラネットフローであることが意図されています。ただし、このドキュメントの手順では、特定のCソースからエクストラネットCフローを受信できるすべてのCレシーバーが、そのソースから非エクストラネットCフローも受信できるようにします。その結果、システムがエクストラネットと非エクストラネットの両方のCフローのCソースである場合、VPNセキュリティ違反が発生する可能性があります。ただし、特定のCソースによって送信されるCフローのセットは、SPの制御下にありません。エクストラネットMVPNサービスを提供するSPは、VPNセキュリティ違反のこの可能性がCソースを管理する顧客によって明確に理解されていることを確認する必要があります。
This specification does not require that UMH-eligible routes be "host routes"; they may be less specific routes. So, it is possible for the NLRI of a UMH-eligible route to contain an address prefix that matches the address of both an extranet C-source and a non-extranet C-source. If such a route is exported from a VPN-S VRF and imported by a VPN-R VRF, C-receivers contained in VPN-R will be able to receive C-flows from the non-extranet C-sources whose addresses match that route. This may result in VPN security violations. Service providers who offer the extranet MVPN service must make sure that this is clearly understood by the customers who administer the distribution of routes from CE routers to PE routers.
この仕様では、UMH対応のルートが「ホストルート」である必要はありません。それらはより具体的なルートではないかもしれません。したがって、UMH適格ルートのNLRIに、エクストラネットCソースと非エクストラネットCソースの両方のアドレスと一致するアドレスプレフィックスを含めることができます。このようなルートがVPN-S VRFからエクスポートされ、VPN-R VRFによってインポートされた場合、VPN-Rに含まれるCレシーバーは、そのルートと一致するアドレスを持つ非エクストラネットCソースからCフローを受信できます。 。これにより、VPNセキュリティ違反が発生する可能性があります。エクストラネットMVPNサービスを提供するサービスプロバイダーは、これがCEルータからPEルータへのルートの配布を管理する顧客によって明確に理解されていることを確認する必要があります。
If the address ambiguities described in Sections 2.1 and 2.2 are not prohibited by deployment of the policies described in Section 2.3.2, VRFs must be able to discard traffic that arrives on the wrong P-tunnel (as specified in Sections 2.3.1 and 7.5). Otherwise, VPN security violations may occur.
セクション2.1および2.2で説明されているアドレスのあいまいさがセクション2.3.2で説明されているポリシーの展開によって禁止されていない場合、VRFは間違ったPトンネルに到着したトラフィックを破棄できなければなりません（セクション2.3.1および7.5で指定されているとおり）。 ）。そうしないと、VPNセキュリティ違反が発生する可能性があります。
[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>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<http://www.rfc-editor.org/info / rfc4360>。
[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] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、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] 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>。
[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>。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャストVPNオートディスカバリルートのワイルドカード」、RFC 6625、DOI 10.17487 / RFC6625、2012年5月、<http://www.rfc-editor.org/info/rfc6625>。
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[RFC7153]ローゼン、EおよびY.レクター、「BGP拡張コミュニティのIANAレジストリ」、RFC 7153、DOI 10.17487 / RFC7153、2014年3月、<http://www.rfc-editor.org/info/rfc7153>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「Protocol Independent Multicast-Sparse Mode（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<http://www.rfc-editor.org/info/rfc7761>。
[MVPN-IR] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", Work in Progress, draft-ietf-bess-ir-03, April 2016.
[MVPN-IR] Rosen、E.、Ed。、Subramanian、K.、Z。Zhang、「マルチキャストVPNのイングレスレプリケーショントンネル」、Work in Progress、draft-ietf-bess-ir-03、2016年4月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, <http://www.rfc-editor.org/info/rfc3446>.
[RFC3446] Kim、D.、Meyer、D.、Kilmer、H。、およびD. Farinacci、「Protocol Independent Multicast（PIM）and Multicast Source Discovery Protocol（MSDP）を使用したエニーキャストRendevous Point（RP）メカニズム」、RFC 3446 、DOI 10.17487 / RFC3446、2003年1月、<http://www.rfc-editor.org/info/rfc3446>。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, <http://www.rfc-editor.org/info/rfc3618>.
[RFC3618] Fenner、B。、編、およびD. Meyer、編、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、DOI 10.17487 / RFC3618、2003年10月、<http：//www.rfc-editor .org / info / rfc3618>。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, <http://www.rfc-editor.org/info/rfc4610>.
[RFC4610] Farinacci、D。およびY. Cai、「プロトコルに依存しないマルチキャスト（PIM）を使用するAnycast-RP」、RFC 4610、DOI 10.17487 / RFC4610、2006年8月、<http://www.rfc-editor.org/info / rfc4610>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[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、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<http：/ /www.rfc-editor.org/info/rfc5015>。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <http://www.rfc-editor.org/info/rfc5059>.
[RFC5059] Bhaskar、N.、Gall、A.、Lingard、J.、S。Venaas、「Bootstrap Router（BSR）Mechanism for Protocol Independent Multicast（PIM）」、RFC 5059、DOI 10.17487 / RFC5059、January 2008、 <http://www.rfc-editor.org/info/rfc5059>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[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>。
Acknowledgments
謝辞
The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt Windisch for their contributions to this work.
著者は、DP Ayyadevara、Robert Kebler、Padmini Misra、Rayen Mohanty、Maria Napierala、Kartik Subramanian、およびKurt Windischのこの作品への貢献に感謝します。
We also wish to thank Lizhong Jin and Rishabh Parekh for their reviews and comments.
また、Lizhong JinとRishabh Parekhのレビューとコメントにも感謝します。
Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and for providing the ASCII art appearing in Section 2.
Jeffrey（Zhaohui）Zhang氏の慎重なレビューとセクション2に記載されているASCIIアートの提供に感謝します。
Contributors
貢献者
Below is a list of other contributing authors, in alphabetical order:
以下は、他の貢献著者のアルファベット順のリストです。
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium
Wim Henderickx Nokia Copernicuslaan 50アントワープ2018ベルギー
Email: wim.henderickx@nokia.com
Praveen Muley Nokia
Praveen Muley Nokia
Email: Praveen.Muley@nokia.com
Ray Qiu Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States
Ray Qiu Juniper Networks、Inc. 1194 North Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国
Email: rqiu@juniper.net
IJsbrand Wijnands Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands Cisco Systems、Inc. De Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Authors' Addresses
著者のアドレス
Yakov Rekhter (editor) Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States
Yakov Rekhter（編集者）Juniper Networks、Inc. 1194 North Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国
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
Rahul Aggarwal Arktan
ラフル・アガーワル・アークタン
Email: raggarwa_1@yahoo.com
Yiqun Cai Alibaba Group 400 S El Camino Real #400 San Mateo, CA 94402 United States
Yiqun Cai Alibaba Group 400 S El Camino Real＃400 San Mateo、CA 94402 United States
Email: yiqun.cai@alibaba-inc.com
Thomas Morin Orange 2 Avenue Pierre-Marzin 22307 Lannion Cedex France
Thomas Morin Orange 2 Avenue Pierre-Marzin 22307ラニオンセデックスフランス
Email: thomas.morin@orange.com