[要約] RFC 4684は、BGP/MPLS IP VPNsにおける制約付き経路配布のための仕様です。このRFCの目的は、VPNルータ間での経路情報の効率的な配布と制御を提供することです。
Network Working Group P. Marques
Request for Comments: 4684 R. Bonica
Updates: 4364 Juniper Networks
Category: Standards Track L. Fang
L. Martini
R. Raszuk
K. Patel
J. Guichard
Cisco Systems, Inc.
November 2006
Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
境界ゲートウェイプロトコル/マルチプロトコルラベルスイッチング（BGP/MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS）の制約されたルート分布
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364.
このドキュメントでは、BGPスピーカーがルートターゲットリーチビリティ情報を交換できるようにするマルチプロトコルBGP（MP-BGP）手順を定義します。この情報は、異なる自律システムまたは同じ自律システムの異なるクラスター間の仮想プライベートネットワーク（VPN）ネットワークレイヤーリーチ可能性情報（NLRI）の伝播を制限するために、ルート配布グラフを構築するために使用できます。このドキュメントは、RFC 4364を更新します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Specification of Requirements ...................................4
3. NLRI Distribution ...............................................4
3.1. Inter-AS VPN Route Distribution ............................4
3.2. Intra-AS VPN Route Distribution ............................6
4. Route Target Membership NLRI Advertisements .....................8
5. Capability Advertisement ........................................9
6. Operation .......................................................9
7. Deployment Considerations ......................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended communities to control the distribution of routes into VRFs. Within a given iBGP mesh, PE routers need only hold routes marked with Route Targets pertaining to VRFs that have local CE attachments.
BGP/MPLS IP VPNSでは、PEルーターはルートターゲット（RT）拡張コミュニティを使用して、VRFへのルートの分布を制御します。特定のIBGPメッシュ内では、PEルーターは、ローカルCEアタッチメントを持つVRFに関連するルートターゲットをマークした保持ルートのみが必要です。
It is common, however, for an autonomous system to use route reflection [2] in order to simplify the process of bringing up a new PE router in the network and to limit the size of the iBGP peering mesh.
ただし、自律システムがネットワーク内に新しいPEルーターを持ち上げ、IBGPピアリングメッシュのサイズを制限するプロセスを簡素化するために、ルートリフレクション[2]を使用することが一般的です。
In such a scenario, as well as when VPNs may have members in more than one autonomous system, the number of routes carried by the inter-cluster or inter-as distribution routers is an important consideration.
このようなシナリオでは、VPNが複数の自律システムにメンバーがいる場合、クラスター間またはAS間の分布ルーターによって運ばれるルートの数は重要な考慮事項です。
In order to limit the VPN routing information that is maintained at a given route reflector, RFC 4364 [3] suggests, in Section 4.3.3, the use of "Cooperative Route Filtering" [7] between route reflectors. This document extends the RFC 4364 [3] Outbound Route Filtering (ORF) work to include support for multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke.
特定のルートリフレクターで維持されているVPNルーティング情報を制限するために、RFC 4364 [3]は、セクション4.3.3で、ルートリフレクター間の「協同ルートフィルタリング」[7]の使用を示唆しています。このドキュメントは、RFC 4364 [3]アウトバウンドルートフィルタリング（ORF）作業を拡張し、複数の自律システムとハブアンドスポークなどの非対称VPNトポロジのサポートを含めるようにします。
Although it would be possible to extend the encoding currently defined for the extended-community ORF in order to achieve this purpose, BGP itself already has all the necessary machinery for dissemination of arbitrary information in a loop-free fashion, both within a single autonomous system, as well as across multiple autonomous systems.
この目的を達成するために、拡張コミュニティORFのために現在定義されているエンコードを拡張することは可能ですが、BGP自体は、単一の自律システム内で、ループフリーの方法で任意の情報を普及させるために必要なすべての機械をすでに持っています、および複数の自律システム全体。
This document builds on the model described in RFC 4364 [3] and on the concept of cooperative route filtering by adding the ability to propagate Route Target membership information between iBGP meshes. It is designed to supersede "cooperative route filtering" for VPN related applications.
このドキュメントは、RFC 4364 [3]で説明されているモデルと、IBGPメッシュ間でルートターゲットメンバーシップ情報を伝播する機能を追加することにより、協同ルートフィルタリングの概念に基づいて構築されます。VPN関連アプリケーションの「協力ルートフィルタリング」に優先するように設計されています。
By using MP-BGP UPDATE messages to propagate Route Target membership information, it is possible to reuse all of this machinery, including route reflection, confederations, and inter-as information loop detection.
MP-BGP更新メッセージを使用してルートターゲットメンバーシップ情報を伝播することにより、ルートリフレクション、コンフェデレーション、情報間の情報ループ検出など、このすべての機械を再利用することができます。
Received Route Target membership information can then be used to restrict advertisement of VPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing information flows in the inverse direction of Route Target membership information.
受信ルートターゲットメンバーシップ情報を使用して、VPN NLRIの広告をそれぞれのルートターゲットを宣伝したピアに制限し、ルート配布グラフを効果的に構築できます。このモデルでは、VPN NLRIルーティング情報がルートターゲットメンバーシップ情報の逆方向に流れます。
This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets, such as VPLS [9].
このメカニズムは、VPLSなどのルートターゲットを使用してルーティング情報の分布を制御するBGP NLRIに適用できます[9]。
Throughout this document, the term NLRI, which expands to "Network Layer Reachability Information", is used to describe routing information carried via MP-BGP updates without any assumption of semantics.
このドキュメント全体を通して、「ネットワークレイヤーリーチビリティ情報」に拡張されるNLRIという用語は、セマンティクスを仮定することなくMP-BGP更新を介して伝達されるルーティング情報を説明するために使用されます。
An NLRI consisting of {origin-as#, route-target} will be referred to as RT membership information for the purpose of the explanation in this document.
{Origin-As＃、Route-Target}で構成されるNLRIは、このドキュメントの説明の目的でRTメンバーシップ情報と呼ばれます。
This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [10]. This section also includes some brief acronym expansion and terminology to aid the reader.
このドキュメントでは、L2VPN、L3VPN、BGPに固有のVPNを含む、プロバイダーが提供するVPNに固有の多くの用語と頭字語を使用しています。これらの用語の多くの定義は、VPN用語文書[10]に記載されている場合があります。このセクションには、読者を支援するための短い頭字語の拡張と用語も含まれています。
AFI Address Family Identifier (a BGP address type)
AFIアドレスファミリ識別子（BGPアドレスタイプ）
BGP Border Gateway Protocol
BGPボーダーゲートウェイプロトコル
BGP/MPLS VPN A Layer 3 VPN implementation based upon BGP and MPLS
BGP/MPLS VPN BGPおよびMPLSに基づくレイヤー3 VPN実装
CE Customer Edge (router)
iBGP Internal BGP (i.e., a BGP peering session that
connects two routers within an autonomous system)
L2VPN Layer 2 Virtual Private Network
L2VPNレイヤー2仮想プライベートネットワーク
L3VPN Layer 3 Virtual Private Network
L3VPNレイヤー3仮想プライベートネットワーク
MP-BGP MultiProtocol-Border Gateway Protocol
MP-BGPマルチプロトコルボーダーゲートウェイプロトコル
MPLS MultiProtocol Label Switching
MPLSマルチプロトコルラベルスイッチング
NLRI Network Layer Reachability Information
NLRIネットワークレイヤーリーチビリティ情報
ORF Outbound Route Filtering
ORFアウトバウンドルートフィルタリング
PE Provider Edge (router)
PEプロバイダーエッジ（ルーター）
RT Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership)
RTルートターゲット（つまり、VPNメンバーシップでネットワークレイヤーの到達可能性情報を条件付けるBGP拡張コミュニティ）
SAFI Subsequence Address Family Identifier (a BGP address sub-type)
SAFIサブシーケンスアドレスファミリ識別子（BGPアドレスサブタイプ）
VPLS Virtual Private LAN Service
VPLS仮想プライベートLANサービス
VPN Virtual Private Network
VPN仮想プライベートネットワーク
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
In order to better understand the problem at hand, it is helpful to divide it in to its inter-Autonomous System (AS) and intra-AS components. Figure 1 represents an arbitrary graph of autonomous systems (a through j) interconnected in an ad hoc fashion. The following discussion ignores the complexity of intra-AS route distribution.
手元の問題をよりよく理解するために、それを自律間システム（AS）およびASコンポーネント内およびASコンポーネントに分割することが役立ちます。図1は、アドホックな方法で相互接続された自律システム（AからJ）の任意のグラフを表しています。以下の議論では、ルート内分布の複雑さを無視しています。
+----------------------------------+
| +---+ +---+ +---+ |
| | a | -- | b | -- | c | |
| +---+ +---+ +---+ |
| | | |
| | | |
| +---+ +---+ +---+ +---+ |
| | d | -- | e | -- | f | -- | j | |
| +---+ +---+ +---+ +---+ |
| / | |
| / | |
| +---+ +---+ +---+ |
| | g | -- | h | -- | i | |
| +---+ +---+ +---+ |
+----------------------------------+
Figure 1. Topology of autonomous systems
図1.自律システムのトポロジ
Let's consider the simple case of a VPN with CE attachments in ASes a and i that uses a single Route Target to control VPN route distribution. Ideally we would like to build a flooding graph for the respective VPN routes that would not include nodes (c, g, h, j). Nodes (c, j) are leafs ASes that do not require this information, whereas nodes (g, h) are not in the shortest inter-as path between (e) and (i) and thus should be excluded via standard BGP path selection.
ASES AおよびIのCEアタッチメントを備えたVPNの単純なケースを考えてみましょう。単一のルートターゲットを使用してVPNルート分布を制御します。理想的には、ノード（C、G、H、J）を含まないそれぞれのVPNルートの洪水グラフを構築したいと考えています。ノード（c、j）はこの情報を必要としない葉のaseであり、一方、ノード（g、h）は（e）と（i）の間の最も短い間隔ではないため、標準のBGPパス選択を介して除外する必要があります。。
In order to achieve this, we will rely on ASa and ASi, generating a NLRI consisting of {origin-as#, route-target} (RT membership information). Receipt of such an advertisement by one of the ASes in the network will signal the need to distribute VPN routes containing this Route Target community to the peer that advertised this route.
これを達成するために、ASAとASIに依存して、{Origin-As＃、Route-Target}（RTメンバーシップ情報）で構成されるNLRIを生成します。ネットワーク内のASEの1つによるこのような広告の受領は、このルートターゲットコミュニティを含むVPNルートをこのルートを宣伝したピアに配布する必要性を示しています。
Using RT membership information that includes both route-target and originator AS number allows BGP speakers to use standard path selection rules concerning as-path length (and other policy mechanisms) to prune duplicate paths in the RT membership information flooding graph, while maintaining the information required to reach all autonomous systems advertising the Route Target.
ルートターゲットとオリジネーターの両方を数値として含むRTメンバーシップ情報を使用すると、BGPスピーカーは、Pathの長さ（およびその他のポリシーメカニズム）に関する標準のパス選択ルールを使用して、情報を維持しながらRTメンバーシップ情報フラッディンググラフの重複パスを剪定することができます。ルートターゲットを宣伝するすべての自律システムに到達するために必要です。
In the example above, AS e needs to maintain a path to AS a in order to flood VPN routing information originating from AS i and vice-versa. It should, however, as default policy, prune less preferred paths such as the longer path to ASi with as-path (g h i).
上記の例では、Eは、私とその逆に由来するVPNルーティング情報をflood濫させるために、Aとしての道を維持する必要があるためです。ただし、デフォルトのポリシーとして、AS-Path（G H I）を使用してASIへの長いパスなど、あまり好ましいパスを剪定する必要があります。
Extending the example above to include AS j as a member of the VPN distribution graph would cause AS f to advertise 2 RT Membership NLRIs to AS e, one containing origin AS i and one containing origin AS j. Although advertising a single path would be sufficient to guarantee that VPN information flows to all VPN member ASes, this is not enough for the desired path selection choices. In the example above, assume that (f j) is selected and advertised. Were that the case, the information concerning the path (f i), which is necessary to prune the arc (e g h i) from the route distribution graph, would be missing.
上記の例をVPN分布グラフのメンバーとして含めるように拡張すると、FはFとして2 RTメンバーシップnlrisをeに宣伝し、1つはiとして原点を含むもの、1つはjとして原点を含む。VPN情報がすべてのVPNメンバーASEに流れることを保証するには、単一のパスを広告するだけで十分ですが、これは目的のパス選択の選択には十分ではありません。上記の例では、（f j）が選択され、宣伝されていると仮定します。その場合、ルート分布グラフからアーク（e g h i）を剪定するために必要なパス（f i）に関する情報が欠落しています。
As with other approaches for building distribution graphs, the benefits of this mechanism are directly proportional to how "sparse" the VPN membership is. Standard RFC2547 inter-AS behavior can be seen as a dense-mode approach, to make the analogy with multicast routing protocols.
分布グラフを構築するための他のアプローチと同様に、このメカニズムの利点は、VPNメンバーシップの「スパース」であることに直接比例します。標準のRFC2547 ASの行動は、マルチキャストルーティングプロトコルとの類似性を作成するために、密なモードアプローチと見なすことができます。
As indicated above, the inter-AS VPN route distribution graph, for a given route-target, is constructed by creating a directed arc on the inverse direction of received Route Target membership UPDATEs containing an NLRI of the form {origin-as#, route-target}.
上記のように、特定のルートターゲットのAS Inter-AS VPNルート分布グラフは、フォームのNLRIを含む受信ルートターゲットメンバーシップの更新の逆方向に向けられたアークを作成することにより構築されます{Origin-As＃、ルートルート-目標}。
Inside the BGP topology of a given autonomous-system, as far as external RT membership information is concerned (route-targets where the as# is not the local as), it is easy to see that standard BGP route selection and advertisement rules [4] will allow a transit AS to create the necessary flooding state.
特定の自律システムのBGPトポロジ内で、外部RTメンバーシップ情報に関する限り（AS＃がローカルASではない場合のルートターゲット）、標準のBGPルートの選択と広告ルールを簡単に確認できます[4]必要な洪水状態を作成するための輸送を許可します。
Consider a IPv4 NLRI prefix, sourced by a single AS, which is distributed via BGP within a given transit AS. BGP protocol rules guarantee that a BGP speaker has a valid route that can be used for forwarding of data packets for that destination prefix, in the inverse path of received routing updates.
特定のトランジットAS内でBGPを介して分布する単一のASで調達されたIPv4 NLRIプレフィックスを考えてみましょう。BGPプロトコルルールは、BGPスピーカーに、受信したルーティングアップデートの逆パスで、その宛先プレフィックスのデータパケットの転送に使用できる有効なルートがあることを保証します。
By the same token, and given that an {origin-as#, route-target} key provides uniqueness between several ASes that may be sourcing this route-target, BGP route selection and advertisement procedures guarantee that a valid VPN route distribution path exists to the origin of the Route Target membership information advertisement.
同様に、{origin-as＃、route-target}キーが、このルートターゲットを調達している可能性のあるいくつかのASEの間で一意性を提供することを考えると、BGPルートの選択と広告手順は、有効なVPNルート分布パスが存在することを保証します。ルートの起源は、メンバーシップ情報広告をターゲットにします。
Route Target membership information that is originated within the autonomous-system, however, requires more careful examination. Several PE routers within a given autonomous-system may source the same NLRI {origin-as#, route-target}, and thus default route advertisement rules are no longer sufficient to guarantee that within the given AS each node in the distribution graph has selected a feasible path to each of the PEs that import the given route-target.
ただし、自律システム内で発信されるルートターゲットメンバーシップ情報は、より慎重な検査が必要です。特定の自律システム内のいくつかのPEルーターは、同じnlri {origin-as＃、route-target}を調達する可能性があります。指定されたルートターゲットをインポートする各PEへの実行可能なパス。
When processing RT membership NLRIs received from internal iBGP peers, it is necessary to consider all available iBGP paths for a given RT prefix, for building the outbound route filter, and not just the best path.
内部IBGPピアから受信したRTメンバーシップNLRIを処理する場合、最適なパスだけでなく、アウトバウンドルートフィルターを構築するために、特定のRTプレフィックスで利用可能なすべてのIBGPパスを考慮する必要があります。
In addition, when advertising Route Target membership information sourced by the local autonomous system to an iBGP peer, a BGP speaker shall modify its procedure to calculate the BGP attributes such that the following apply:
さらに、ローカルの自律システムによってIBGPピアに供給された広告ルートターゲットメンバーシップ情報をターゲットにする場合、BGPスピーカーはその手順を変更してBGP属性を計算するように変更します。
i. When advertising RT membership NLRI to a route-reflector client, the Originator attribute shall be set to the router-id of the advertiser, and the Next-hop attribute shall be set of the local address for that session.
i. RTメンバーシップNLRIをルートリフレクタークライアントに広告する場合、Originator属性は広告主のRouter-IDに設定され、次のホップ属性はそのセッションのローカルアドレスのセットとするものとします。
ii. When advertising an RT membership NLRI to a non-client peer, if the best path as selected by the path selection procedure described in Section 9.1 of the base BGP specification [4] is a route received from a non-client peer, and if there is an alternative path to the same destination from a client, the attributes of the client path are advertised to the peer.
ii。RTメンバーシップNLRIを非クライアントピアに宣伝する場合、ベースBGP仕様のセクション9.1で説明されているパス選択手順[4]で選択された最適なパスは、非クライアントピアから受信したルートであり、ある場合、クライアントから同じ宛先への代替パスであり、クライアントパスの属性はピアに宣伝されます。
The first of these route advertisement rules is designed such that the originator of an RT membership NLRI does not drop an RT membership NLRI that is reflected back to it, thus allowing the route reflector to use this RT membership NLRI in order to signal the client that it should distribute VPN routes with the specific target towards the reflector.
これらのルート広告ルールの最初のルールは、RTメンバーシップNLRIのオリジネーターがそれに反映されるRTメンバーリングNLRIをドロップしないように設計されているため、ルートリフレクターがこのRTメンバーリングNLRIを使用して、クライアントに信号を送ることができます。特定のターゲットを備えたVPNルートをリフレクターに分配する必要があります。
The second rule allows any BGP speaker present in an iBGP mesh to signal the interest of its route reflection clients in receiving VPN routes for that target.
2番目のルールでは、IBGPメッシュに存在するBGPスピーカーが、そのターゲットのVPNルートを受信する際にルートリフレクションクライアントの関心を示すことができます。
These procedures assume that the autonomous-system route reflection topology is configured such that IPv4 unicast routing would work correctly. For instance, route reflection clusters must be contiguous.
これらの手順では、IPV4ユニキャストルーティングが正しく機能するように、自律システムルートリフレクショントポロジが構成されていると想定しています。たとえば、ルート反射クラスターは隣接する必要があります。
An alternative solution to the procedure given above would have been to source different routes per PE, such as NLRI of the form {originator-id, route-target}, and to aggregate them at the edge of the network. The solution adopted is considered advantageous over the former in that it requires less routing-information within a given AS.
上記の手順の代替ソリューションは、フォーム{Originator-ID、ルートターゲット}のNLRIなど、PEごとに異なるルートを調達し、ネットワークの端でそれらを集約することでした。採用されたソリューションは、特定のAS内のルーティング情報が少ないという点で、前者よりも有利であると考えられています。
Route Target membership NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [5]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, SAFI=132).
ルートターゲットメンバーシップNLRIは、MP_REACH_NLRIおよびMP_UNREACH_NLRI属性[5]を使用してBGP更新メッセージで宣伝されています。このNLRIを識別するために使用される[afi、safi]値ペアは（afi = 1、safi = 132）です。
The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address whenever the length of NextHop address is 4 octets, and as a IPv6 address whenever the length of the NextHop address is 16 octets.
MP_REACH_NLRI属性の次のホップフィールドは、NEXTHOPアドレスの長さが4オクテットの場合はいつでもIPv4アドレスとして解釈され、NEXTHOPアドレスの長さが16オクテットの場合はいつでもIPv6アドレスとして解釈されます。
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 96 bits, encoded as defined in Section 4 of [5].
MP_REACH_NLRIおよびMP_UNREACH_NLRIのNLRIフィールドは、[5]のセクション4で定義されているようにエンコードされた0〜96ビットのプレフィックスです。
This prefix is structured as follows:
このプレフィックスは次のように構成されています。
+-------------------------------+
| origin as (4 octets) |
+-------------------------------+
| route target (8 octets) |
+ +
| |
+-------------------------------+
Except for the default route target, which is encoded as a zero-length prefix, the minimum prefix length is 32 bits. As the origin-as field cannot be interpreted as a prefix.
ゼロの長さのプレフィックスとしてエンコードされるデフォルトルートターゲットを除き、最小プレフィックスの長さは32ビットです。ASフィールドとしてのOrigin-as Asは、プレフィックスとして解釈することはできません。
Route targets can then be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator [6].
その後、ルートターゲットはプレフィックスとして表現できます。たとえば、プレフィックスは、特定のグローバル管理者によって割り当てられたすべてのルートターゲット拡張コミュニティ[6]を包含します。
The default route target can be used to indicate to a peer the willingness to receive all VPN route advertisements such as, for instance, the case of a route reflector speaking to one of its PE router clients.
デフォルトのルートターゲットを使用して、たとえば、PEルータークライアントの1人に話しかけるルートリフレクターの場合など、すべてのVPNルート広告を受け取る意欲をピアに示すことができます。
A BGP speaker that wishes to exchange Route Target membership information must use the Multiprotocol Extensions Capability Code, as defined in RFC 2858 [5], to advertise the corresponding (AFI, SAFI) pair.
ルートターゲットメンバーシップ情報を交換したいBGPスピーカーは、RFC 2858 [5]で定義されているマルチプロトコル拡張機能コードを使用して、対応する（AFI、SAFI）ペアを宣伝する必要があります。
A BGP speaker MAY participate in the distribution of Route Target information without using the learned information for purposes of VPN NLRI output route filtering, although this is discouraged.
BGPスピーカーは、VPN NLRI出力ルートフィルタリングの目的で学習した情報を使用せずにルートターゲット情報の配布に参加する場合がありますが、これは推奨されていません。
A VPN NLRI route should be advertised to a peer that participates in the exchange of Route Target membership information if that peer has advertised either the default Route Target membership NLRI or a Route Target membership NLRI containing any of the targets contained in the extended communities attribute of the VPN route in question.
VPN NLRIルートは、そのピアがデフォルトのルートターゲットメンバーリングNLRIまたはルートターゲットメンバーリングNLRIを宣伝している場合、ルートターゲットメンバーシップ情報の交換に参加するピアに宣伝する必要があります。問題のVPNルート。
When a BGP speaker receives a BGP UPDATE that advertises or withdraws a given Route Target membership NLRI, it should examine the RIB-OUTs of VPN NLRIs and re-evaluate the advertisement status of routes that match the Route Target in question.
BGPスピーカーが特定のルートターゲットメンバーシップNLRIを宣伝または撤回するBGPアップデートを受信する場合、VPN NLRISのリブアウトを調べ、問題のルートターゲットに一致するルートの広告ステータスを再評価する必要があります。
A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information.
BGPスピーカーは、ルートターゲットメンバーシップ情報から導出されるルート分布グラフの前および現在の状態の間の移行に必要なBGP VPNルートの更新（広告および/または撤回）の最小セットを生成する必要があります。
As a hint that initial RT membership exchange is complete, implementations SHOULD generate an End-of-RIB marker, as defined in [8], for the Route Target membership (afi, safi), regardless of whether graceful-restart is enabled on the BGP session. This allows the receiver to know when it has received the full contents of the peer's membership information. The exchange of VPN NLRI should follow the receipt of the End-of-RIB markers.
初期のRTメンバーシップ交換が完了したというヒントとして、実装は[8]で定義されているように、Route Target Membership（AFI、SAFI）で[8]で定義されているRIBの終了マーカーを生成する必要があります。BGPセッション。これにより、受信者は、ピアのメンバーシップ情報の完全なコンテンツをいつ受け取ったかを知ることができます。VPN NLRIの交換は、RIBの終了マーカーの受領に従う必要があります。
If a BGP speaker chooses to delay the advertisement of BGP VPN route updates until it receives this End-of-RIB marker, it MUST limit that delay to an upper bound. By default, a 60 second value should be used.
BGPスピーカーがBGP VPNルートの更新の広告を遅らせることを選択した場合、このRIBの終了マーカーが受信されるまで、その遅延を上限に制限する必要があります。デフォルトでは、60秒の値を使用する必要があります。
This mechanism reduces the scaling requirements that are imposed on route reflectors by limiting the number of VPN routes and events that a reflector has to process to the VPN routes used by its direct clients. By default, a reflector must scale in terms of the total number of VPN routes present on the network.
このメカニズムは、リフレクターが直接クライアントが使用するVPNルートに処理しなければならないVPNルートとイベントの数を制限することにより、ルートリフレクターに課されるスケーリング要件を削減します。デフォルトでは、リフレクターは、ネットワークに存在するVPNルートの総数の観点からスケーリングする必要があります。
This also means that it is now possible to reduce the load imposed on a given reflector by dividing the PE routers present on its cluster into a new set of clusters. This is a localized configuration change that need not affect any system outside this cluster.
これはまた、クラスターに存在するPEルーターを新しいクラスターのセットに分割することにより、特定の反射器に課される負荷を減らすことができることを意味します。これは、このクラスター外のシステムに影響を与える必要はないローカライズされた構成変更です。
The effectiveness of RT-based filtering depends on how sparse the VPN membership is.
RTベースのフィルタリングの有効性は、VPNメンバーシップがどれほどスパースであるかに依存します。
The same policy mechanisms applicable to other NLRIs are also applicable to RT membership information. This gives a network operator the option of controlling which VPN routes get advertised in an inter-domain border by filtering the acceptable RT membership advertisements inbound.
他のNLRIに適用される同じポリシーメカニズムも、RTメンバーシップ情報に適用できます。これにより、ネットワークオペレーターは、許容可能なRTメンバーシップ広告をインバウンドすることにより、どのVPNルートがドメイン間の境界で宣伝されるかを制御するオプションを提供します。
For instance, in the inter-as case, it is likely that a given VPN is connected only to a subset of all participating ASes. The only current mechanism to limit the scope of VPN route flooding is through manual filtering on the external BGP border routers. With the current proposal, such filtering can be performed according to the dynamic Route Target membership information.
たとえば、Inter-ASの場合、特定のVPNは、参加しているすべてのASEのサブセットにのみ接続されている可能性があります。VPNルートフラッディングの範囲を制限する唯一の電流メカニズムは、外部BGPボーダールーターの手動フィルタリングを使用することです。現在の提案を使用すると、そのようなフィルタリングは、動的ルートターゲットメンバーシップ情報に従って実行できます。
In some inter-as deployments, not all RTs used for a given VPN have external significance. For example, a VPN can use a hub RT and a spoke RT internally to an autonomous-system. The spoke RT does not have meaning outside this AS, so it may be stripped at an external border router. The same policy rules that result in extended community filtering can be applied to RT membership information in order to avoid advertising an RT membership NLRI for the spoke-RT in the example above.
一部のAS展開では、特定のVPNに使用されるすべてのRTが外部的に重要ではありません。たとえば、VPNはハブRTを使用し、自律システムに内部的にRTを使用することができます。スポークRTにはこれ以外の意味がないため、外部の境界線ルーターで剥がれる可能性があります。上記の例では、SPOKE-RTのRTメンバーリングNLRIを宣伝することを避けるために、拡張コミュニティフィルタリングをもたらす同じポリシールールをRTメンバーシップ情報に適用できます。
Throughout this document, we assume that autonomous-systems agree on an RT assignment convention. RT translation at the external border router boundary is considered a local implementation decision, as it should not affect inter-operability.
このドキュメント全体で、自律システムがRT割り当て条約に同意すると想定しています。外部ボーダールーターの境界でのRT翻訳は、相互作用性に影響を与えるべきではないため、ローカルの実装決定と見なされます。
This document does not alter the security properties of BGP-based VPNs. However, note that output route filters built from RT membership information NLRIs are not intended for security purposes. When exchanging routing information between separate administrative domains, it is a good practice to filter all incoming and outgoing NLRIs by some other means in addition to RT membership information. Implementations SHOULD also provide means to filter RT membership information.
このドキュメントは、BGPベースのVPNのセキュリティプロパティを変更しません。ただし、RTメンバーシップ情報から構築された出力ルートフィルターNLRIは、セキュリティ目的ではないことに注意してください。別の管理ドメイン間でルーティング情報を交換する場合、RTメンバーシップ情報に加えて、すべての着信および発信NLRIを他の手段でフィルタリングすることをお勧めします。実装は、RTメンバーシップ情報をフィルタリングする手段も提供する必要があります。
This proposal is based on the extended community route filtering mechanism defined in [7].
この提案は、[7]で定義されている拡張コミュニティルートフィルタリングメカニズムに基づいています。
Ahmed Guetari was instrumental in defining requirements for this proposal.
アーメド・グタリは、この提案の要件を定義するのに役立ちました。
The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave Ward, John Scudder, and Jerry Ash for their comments and suggestions.
著者はまた、Yakov Rekhter、Dan Tappan、Dave Ward、John Scudder、およびJerry Ashのコメントと提案に感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[2] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、2006年4月。
[3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[3] Rosen、E。and Y. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[4] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[5] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[6] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[6] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[7] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, December 2004.
[7] Chen、E。およびY. Rekhter、「BGP-4の協同ルートフィルタリング機能」、2004年12月、進行中の作業。
[8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
[8] Sangli、S.、Rekhter、Y.、Fernando、R.、Scudder、J。、およびE. Chen、「BGPの優雅な再起動メカニズム」、2004年6月の作業。
[9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work in Progress, April 2005.
[9] Kompella、K。およびY. Rekhter、「仮想プライベートLANサービス」、2005年4月、進行中の作業。
[10] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[10] Andersson、L。およびT. Madsen、「プロバイダーは仮想プライベートネットワーク（VPN）用語をプロビジョニングします」、RFC 4026、2005年3月。
Authors' Addresses
著者のアドレス
Pedro Marques Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Pedro Marques Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US
EMail: roque@juniper.net
Ronald Bonica Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Ronald Bonica Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US
EMail: rbonica@juniper.net
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
Luyuan Fang Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 US
EMail: lufang@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
US
EMail: lmartini@cisco.com
Robert Raszuk Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
Robert Raszuk Cisco Systems、Inc。170 West Tasman Dr San Jose、CA 95134 US
EMail: rraszuk@cisco.com
Keyur Patel Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
Keyur Patel Cisco Systems、Inc。170 West Tasman Dr San Jose、CA 95134 US
EMail: keyupate@cisco.com
Jim Guichard Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
Jim Guichard Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 US
EMail: jguichar@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。