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)
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).
著作権（C）IETFトラスト（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 VPNのでは、PEルータはのVRFへのルートの分布を制御するためのルートターゲット（RT）拡張コミュニティを使用します。与えられたの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ルータをもたらすプロセスを簡略化するために、ルート・リフレクション[2]を使用するとのiBGPピアリングのメッシュの大きさを制限することは、しかしながら、一般的です。
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は、複数の自律システム内のメンバーを有することができるでは、クラスタ間またはインターなどの配信ルータによって搬送される経路の数は重要な考慮事項です。
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.
{＃、ルートターゲットとして原点}からなる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、L3VPNsおよびBGPに特有のものも含めプロバイダープロビジョニング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)
CEカスタマエッジ（ルータ）のiBGP内部BGP（すなわち、自律システム内の2台のルータを接続するBGPピアリング・セッション）
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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コンポーネントの中でそれを分割すると便利です。図1は、自律システム（Jスルー）の任意のグラフは、アドホックな方法で相互接続を表します。以下の議論は、イントラASルート分布の複雑さを無視します。
+----------------------------------+
| +---+ +---+ +---+ |
| | 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.
VPNルート分布を制御するために、単一のルートターゲットを使用するのは、ASのaのCEが添付されたVPNの簡単な場合を考えると私。理想的には、ノード（C、G、H、J）を含んでいないであろうそれぞれのVPNルートのフラッディンググラフを構築したいと思います。こうしてノードノード（G、H）が最短相互として（E）との間の経路と、（i）ではないのに対し、（C、j）は、この情報を必要としないリーフののASであるとは、標準的な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.
これを達成するために、我々は、（RTメンバーシップ情報）{＃、ルートターゲットとして原点}からなるNLRIを生成し、ASAとのASiに依存します。ネットワーク内のASのいずれかによって、このような広告の受信はこのルートをアドバタイズピアにこのルートターゲットコミュニティを含む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スピーカは、ASパス長（及び他のポリシーメカニズム）に関する標準的な経路選択ルールを使用することを可能にするので、ルートターゲットと発信の両方を含む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とIとその逆AS由来VPNルーティング情報をフラッディングするためにするようにパスを維持する必要があります。しかし、デフォルトのポリシーとして、例えば、パス（グラム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分布グラフのメンバーとしてjと含むように上記の例を拡張すると、iと一つjと原点を含むものとして原点を含むものをEとする2 RT会員たNLRIをアドバタイズするようにF引き起こします。単一パスを宣伝するVPN情報は、すべてのVPNメンバーのASに流れることを保証するのに十分であるが、これは所望の経路選択の選択肢のために十分ではありません。上記の例では、（F jの）選択とアドバタイズされると仮定する。ルート分布グラフからアーク（E gはH i）を整理する必要がある場合、パスに関する情報（I F）は、欠落していることになるたこと。
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間VPN経路分布グラフは、所与のルートターゲットのために、フォーム{原点として＃、ルートのNLRIを含む受信したルートターゲットのメンバーシップ更新の逆方向に向けられたアークを作成することによって構成されています-ターゲット}。
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メンバーシップ情報は（＃のようにローカルではないルートターゲット）に関しては、簡単に確認することができ、標準BGPルート選択や広告ルール[4必要なフラッディング状態を作成するために、AS]輸送が可能になります。
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.
同様に、キーは、このルートターゲットを供給することができるいくつかのAS間の一意性を提供{原点として＃、ルートターゲット}と仮定すると、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 {原点として＃、ルートターゲットを}ソースできるので、デフォルトルートの広告ルールはもはや分布グラフ内の各ノードとして与え内で選択されたことを保証するのに十分ではありません所定のルートターゲットをインポートする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.
たNLRIは、内部iBGPピアから受信したRTメンバーシップを処理するとき、アウトバウンドルートフィルタ、およびだけではなく、最適なパスを構築するため、与えられた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.
私。ルートリフレクタクライアントにRT会員NLRIを広告する場合は、発信属性は、広告主のルータ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。ベースBGP仕様のセクション9.1に記載の経路選択手順により選択された最良パスとしてた場合、非クライアントピアにRT会員NLRIを広告するとき、[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.
第二のルールは、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.
上記の手順の別の解決策は、フォーム{発信-ID、ルートターゲット}のNLRIとしてPEごとに異なる経路を供給するために、ネットワークのエッジでそれらを集約することであったであろう。それは与えられた範囲内以下のルーティング情報を必要とするに採用溶液を前者に比べて有利であると考えられます。
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 UPDATEメッセージでアドバタイズされます。このNLRIを識別するために使用される[AFI、SAFI]値のペアは、（AFI = 1、サフィ= 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.
ネクストホップアドレスの長さが4つのオクテットであるときはいつでも、およびIPv6アドレスとしてネクストホップアドレスの長さは16オクテットであるときはいつでもMP_REACH_NLRI属性のネクストホップフィールドは、IPv4アドレスとして解釈されなければなりません。
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ビットです。原点としてフィールド接頭辞として解釈することはできません。
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ルータクライアントのいずれかに言えば、のようにすべての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.
対応する（AFI、SAFI）ペアをアドバタイズするために、RFC 2858 [5]で定義されるように、マルチプロトコル拡張機能コードを使用しなければならないルートターゲット・メンバーシップ情報を交換したいBGPスピーカ。
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 UPDATEを受信すると、VPNたNLRIのRIBアウトを調べる必要があり、問題のルートターゲットに一致するルートの広告のステータスを再評価します。
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ルートアップデート（広告及び/又はwithdrawls）の最小セットを生成すべきです。
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.
[8]で定義されるように、初期RTメンバーシップ交換が完了したことをヒントとして、実装にかかわらず、グレースフルリスタートを有効にするかどうかの、ルートターゲット・メンバーシップ（AFI、サフィ）のために、エンド・オブ・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.
それは、このエンドの-RIBマーカーを受信するまでBGPスピーカは、BGP VPNルートアップデートの広告を遅らせることを選択した場合、それが上限にその遅延を制限しなければなりません。デフォルトでは、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会員資格情報に適用されます。これは、ネットワークオペレータにVPNルートがインバウンド許容RT会員資格の広告をフィルタリングすることにより、ドメイン間の国境で広告を取得制御するオプションを提供します。
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.
例えば、AS間場合には、指定されたVPNのみ参加するすべてのASのサブセットに接続されている可能性があります。 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.
いくつかの間などの展開では、与えられたVPNのために使用されていないすべてのRTは、外部の意義を持っています。たとえば、VPNは、自律システムに内部ハブRTとスポークRTを使用することができます。スポークRTがこのAS外の意味を持っていないので、それは外部の境界ルータでストリッピングすることができます。拡張コミュニティフィルタリングの結果と同じポリシールールは、上記の例では、スポーク-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.
アーメドGuetariは、この提案のための要件を定義するに尽力しました。
The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave Ward, John Scudder, and Jerry Ash for their comments and suggestions.
著者はまた、彼らのコメントや提案のためのヤコフ・レックター、ダンタッパン、デイブ・ワード、ジョン・スカダー、とジェリーアッシュに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[2]ベイツ、T.、チェン、E.、およびR.チャンドラ、 "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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、RFC 2858、2000年6月 "BGP-4のためのマルチプロトコル拡張機能"。
[6] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[6]サングリ、S.、タッパン、D.、およびY. Rekhterは、RFC 4360、2006年2月、 "BGPはコミュニティ属性を拡張します"。
[7] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, December 2004.
[7]チェン、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.
進歩、2004年6月[8]サングリ、S.、Rekhter、Y.、フェルナンド、R.、スカダー、J.、およびE.チェン、 "BGPのためのグレースフルリスタート機構"、ワーク。
[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]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
Authors' Addresses
著者のアドレス
Pedro Marques Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ペドロ・マルケスジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: roque@juniper.net
メールアドレス：roque@juniper.net
Ronald Bonica Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ロナルドBonicaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: rbonica@juniper.net
メールアドレス：rbonica@juniper.net
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
Luyuan牙シスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719米国
EMail: lufang@cisco.com
メールアドレス：lufang@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO 80112米国
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
Robert Raszuk Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
ロバートRaszukシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134米国
EMail: rraszuk@cisco.com
メールアドレス：rraszuk@cisco.com
Keyur Patel Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
Keyurパテルシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134米国
EMail: keyupate@cisco.com
メールアドレス：keyupate@cisco.com
Jim Guichard Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
ジム・ギシャールシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719米国
EMail: jguichar@cisco.com
メールアドレス：jguichar@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。