RFC4684 日本語訳

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

捕獲許可がコメントのために要求するワーキンググループP.をネットワークでつないでください: 4684のR.Bonicaアップデート: 4364年の杜松はカテゴリをネットワークでつなぎます: 標準化過程L.牙のL.マティーニR.Raszuk K.パテルJ.ギシャールシスコシステムズInc.2006年11月

                  Constrained Route Distribution for
    Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
         Internet Protocol (IP) Virtual Private Networks (VPNs)

ボーダ・ゲイトウェイ・プロトコル/MultiProtocolラベルの切り換え(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(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スピーカーがRoute Target可到達性情報を交換できるMulti-プロトコルBGP(MP-BGP)手順を定義します。 同じ自律システムの異なった自律システムか異なったクラスタの間のVirtual兵士のNetwork(VPN)ネットワークLayer Reachability情報(NLRI)の伝播を制限するためにルート分配グラフを築き上げるのにこの情報を使用できます。 このドキュメントはRFC4364をアップデートします。

Marques, et al.             Standards Track                     [Page 1]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[1ページ]

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

1. 序論…2 1.1. 用語…3 2. 要件の仕様…4 3. NLRI分配…4 3.1. 相互、VPNは分配を発送します…4 3.2. イントラ、-、VPNは分配を発送します…6 4. 目標会員資格NLRI広告を発送してください…8 5. 能力広告…9 6. 操作…9 7. 展開問題…10 8. セキュリティ問題…11 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…12

1.  Introduction

1. 序論

   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ルータは、ルートの分配をVRFsに制御するのにRoute Target(RT)の拡張共同体を使用します。 与えられたiBGPメッシュの中では、PEルータは、Route Targetsが地方のCE付属を持っているVRFsに関係する状態でルートがマークされるままにするだけでよいです。

   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.

しかしながら、自律システムが[2] ネットワークで新しいPEルータを持って来る過程を簡素化するのにルート反射を使用して、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.

または、VPNsが1つ以上の自律システムにメンバーがいるかもしれない時と同様にそのようなシナリオでは、ルートの数が相互クラスタによって運ばれた、相互、分配ルータは重要な考慮すべき事柄です。

   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ルーティング情報を制限するために、RFC4364[3]は示されます、セクション4.3.3で、ルート反射鏡の間の「協力的なルートフィルタリング」[7]の使用。 このドキュメントは、ハブやスポークなどの複数の自律システムと非対称のVPN topologiesのサポートを含むようにRFC4364[3]外国行きのRoute Filtering(ORF)仕事を広げています。

   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自身は単一の自律システム以内と無輪のファッションと、複数の自律システムの向こう側に既に任意の情報の普及のためのすべての必要な機械を持ちます。

Marques, et al.             Standards Track                     [Page 2]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[2ページ]

   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.

このドキュメントは、RFC4364[3]で説明されたモデルの上と、そして、協力的なルートフィルタリングの概念の上にiBGPメッシュの間のRoute Target会員資格情報を伝播する能力を加えることによって、建てられます。 それは、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.

そして、Route Target会員資格情報を伝播するMP-BGP UPDATEメッセージを使用することによって、この機械のすべてを再利用するのは可能です、ルート反射を含んでいて、同盟者、相互、情報輪の検出。

   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の広告を彼らのそれぞれのRoute Targetsの広告を出した同輩に制限するのに受信されたRoute Target会員資格情報を使用できます、事実上、ルート分配グラフを築き上げて。 このモデルでは、VPN NLRIルーティング情報はRoute Target会員資格情報の逆さの方向に流れます。

   This mechanism is applicable to any BGP NLRI that controls the
   distribution of routing information by using Route Targets, such as
   VPLS [9].

このメカニズムはRoute Targetsを使用することによってルーティング情報の分配を制御するどんなBGP NLRIにも適切です、VPLS[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会員資格情報と呼ばれるでしょう。

1.1.  Terminology

1.1. 用語

   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.

このドキュメントはProviderによって食糧を供給されたVPNsに特定の多くの用語と頭文字語を使用します、L2VPNs、L3VPNs、およびBGPに特定のそれらを含んでいて。 これらの用語の多くの定義は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に基づくBGP/MPLS VPN A Layer3VPN実現

   CE             Customer Edge (router)

Ce顧客縁(ルータ)

Marques, et al.             Standards Track                     [Page 3]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[3ページ]

   iBGP           Internal BGP (i.e., a BGP peering session that
                  connects two routers within an autonomous system)

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 MultiProtocolボーダ・ゲイトウェイ・プロトコル

   MPLS           MultiProtocol Label Switching

MPLS MultiProtocolラベルの切り換え

   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ルート目標(すなわち、BGPはVPN会員資格でネットワーク層可到達性情報を条件とさせる共同体を広げました)

   SAFI           Subsequence Address Family Identifier (a BGP address
                  sub-type)

サフィ続きアドレス家族識別子(BGPアドレスサブタイプ)

   VPLS           Virtual Private LAN Service

VPLSの仮想の個人的なLANサービス

   VPN            Virtual Private Network

VPNの仮想の私設のネットワーク

2.  Specification of Requirements

2. 要件の仕様

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

3.  NLRI Distribution

3. NLRI分配

3.1.  Inter-AS VPN Route Distribution

3.1. 相互、VPNは分配を発送します。

   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.

当面の問題を理解するほうがよいために、相互Autonomous System(AS)とイントラ-ASの部品にそれに分かれるのは役立っています。 図1は臨時のファッションでインタコネクトされた自律システム(aからj)の任意のグラフを表します。 以下の議論はイントラ-ASルート分配の複雑さを無視します。

Marques, et al.             Standards Track                     [Page 4]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[4ページ]

                     +----------------------------------+
                     | +---+    +---+    +---+          |
                     | | a | -- | b | -- | c |          |
                     | +---+    +---+    +---+          |
                     |   |        |                     |
                     |   |        |                     |
                     | +---+    +---+    +---+    +---+ |
                     | | d | -- | e | -- | f | -- | j | |
                     | +---+    +---+    +---+    +---+ |
                     |        /            |            |
                     |       /             |            |
                     | +---+    +---+    +---+          |
                     | | g | -- | h | -- | i |          |
                     | +---+    +---+    +---+          |
                     +----------------------------------+

+----------------------------------+ | +---+ +---+ +---+ | | | 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.

CE付属がASes aとiにある独身のRoute Targetを使用するVPNの簡単なケースがVPNルート分配を制御すると考えましょう。 理想的に、ノード(c、g、h、j)を含んでいないそれぞれのVPNルートのための氾濫グラフを築き上げたいと思います。 そして、ノード(c、j)がそうである、葉、この情報ではなく、ノード(g、h)を必要とするASesが最も不足するところにない、相互、(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を当てにするつもりです、NLRIを発生させるのが成って起源、-、#、ルート目標、(RT会員資格情報。) ネットワークにおけるASesの1つによるそのような広告の領収書はこのルートの広告を出した同輩にこのRoute Target共同体を含む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.

ルート目標と創始者AS番号の両方を含んでいるRT会員資格情報を使用するのに、情報が、Route Targetの広告を出しながらすべての自律システムに達するのを必要としたと主張している間、BGPスピーカーは、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).

例では、上では、AS eは、AS iと副versaから発するVPNルーティング情報をあふれさせるようにAS aに経路を維持する必要があります。 それがそうするべきである、しかしながら、デフォルト方針としての以下が経路としてASiへの、より長い経路などの経路を好んだプルーン(g h i)。

Marques, et al.             Standards Track                     [Page 5]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[5ページ]

   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分配グラフのメンバーとしてAS jを含むためには上記の例を広げるのはAS fにAS e(起源AS iと起源AS jを含む1つを含む1つ)に2RT Membership NLRIsに広告を出させるでしょう。 ただ一つの経路の広告を出すのはVPN情報がすべてのVPNメンバーASesに注ぐのを保証するために十分でしょうが、必要な経路選択選択には、これは十分ではありません。 例では、上では、(f j)が選択されて、広告を出すと仮定してください。 経路(f i)の情報(ルート分配グラフからアーク(e g h 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の振舞いを濃いモードアプローチと考えることができます。

3.2.  Intra-AS VPN Route Distribution

3.2. イントラ、-、VPNは分配を発送します。

   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}.

形式のNLRIを含んでいて、相互AS VPNルート分配グラフが与えられたルート目標のために上で示されるように容認されたRoute Target会員資格UPDATEsの逆さの指示で指示されたアークを作成することによって作図される、起源、-、#、ルート目標

   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.

外部のRT会員資格情報は関係があるのと同じくらい遠い与えられた自律システムのBGPトポロジー、(どこをルートで狙うか、#、が地方でない、)、トランジット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.

同じ象徴であり、与えられる、それ、起源、-、#、ルート目標、キーはこのルート目標の出典を明示しているかもしれない数個のASesの間のユニークさを提供して、BGPは選択を発送して、広告手順は、有効なVPNルート分配経路がRoute Target会員資格情報広告の起源に存在するのを保証します。

Marques, et al.             Standards Track                     [Page 6]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[6ページ]

   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.

しかしながら、自律システムの中で溯源されるルートTarget会員資格情報は、より慎重な試験を必要とします。 当然のことの自律システムの中のいくつかのPEルータが同じNLRIの出典を明示するかもしれない、起源、-、#、ルート目標、その結果、デフォルトルート広告規則は、そんなに中で分配グラフによる各ノードが与えられたルート目標を輸入するそれぞれのPEsに実行可能経路を選択したのを与えられたASに保証するためにもう十分ではありません。

   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.

処理RT会員資格NLRIsが内部のiBGP同輩から受信したとき、与えられた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同輩に出典を明示されたRoute Target会員資格情報の広告を出すとき、さらに、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属性は広告主のルータイドに設定されるものとします、そして、Next-ホップ属性はそのセッションのためのローカルアドレスのセットになるでしょう。

   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仕様[4]のセクション9.1で説明された経路選択手順によって選択される中で最も良い経路が非クライアント同輩から受け取られたルートであり、同じ目的地への迂回経路がクライアントからあれば、クライアント道の属性が同輩に広告に掲載されるなら。

   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.

NLRIがするRT会員資格の創始者はこれらのルート広告規則の1番目が設計されたそのようなものであるので、それに映し出されるRT会員資格NLRIを落としません、その結果、特定の目標で反射鏡に向かってVPNルートを分配するべきであるとクライアントに合図するためにルート反射鏡がこのRT会員資格NLRIを使用するのを許容します。

   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ユニキャストルーティングが正しく利くように構成されると仮定します。 例えば、ルート反射クラスタは隣接であるに違いありません。

Marques, et al.             Standards Track                     [Page 7]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[7ページ]

   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.

上に与えられた手順の代替の解決は、形式のNLRIなどのPEあたりの異なったルートで創始者イド、ルート目標の出典を明示して、ネットワークの縁でそれらに集めるだろうことでした。 与えられたASの中で、より少ないルーティング情報を必要とするので、採用された解決策は前者の上で有利であると考えられます。

4.  Route Target Membership NLRI Advertisements

4. ルート目標会員資格NLRI広告

   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).

BGP UPDATEメッセージにMP_REACH_NLRIとMP_UNREACH_NLRI属性[5]を使用することでルートTarget会員資格NLRIの広告を出します。 このNLRIを特定するのに使用される[AFI、サフィ]値の組は(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.

NextHopアドレスの長さが4つの八重奏であり、IPv6アドレスとして解釈するときはいつも、REACH_NLRIが結果と考えるMP_のNext Hop分野はNextHopアドレスの長さが16の八重奏であるときはいつも、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)   |
        +                               +
        |                               |
        +-------------------------------+

+-------------------------------+ | (4つの八重奏)としての起源| +-------------------------------+ | ルート目標(8つの八重奏)| + + | | +-------------------------------+

   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].

そして、接頭語としてルート目標を急送できます。例えば、接頭語は、そこが拡張共同体が与えられたGlobal Administrator[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ルート広告を受け取る意欲を同輩に示すのにデフォルトルート目標を使用できます。

Marques, et al.             Standards Track                     [Page 8]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[8ページ]

5.  Capability Advertisement

5. 能力広告

   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.

Route Target会員資格情報を交換したがっているBGPスピーカーはMultiprotocol Extensions Capability Codeを使用しなければなりません、対応する(AFI、サフィ)組の広告を出すためにRFC2858[5]で定義されるように。

   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.

VPN NLRI出力ルートフィルタリングの目的に経験から学んだ知識を使用しないで、BGPスピーカーはRoute Target情報の分配に参加するかもしれません、これががっかりしていますが。

6.  Operation

6. 操作

   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ルートの拡張共同体属性に含まれたデフォルトRoute Target会員資格NLRIか目標のRoute Targetの会員資格のNLRIの含んでいるどれかのどちらかの広告を出したならRoute Target会員資格情報の交換に参加する同輩にVPN NLRIルートの広告を出すべきです。

   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.

NLRI、BGPスピーカーが与えられたRoute Target会員資格を広告を出すか、または引き下がらせるBGP UPDATEを受け取るとき、それはVPN NLRIsのRIB-OUTsを調べて、問題のRoute Targetに合っているルートの広告状態を再評価するべきです。

   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スピーカーはRoute Target会員資格情報から得られるルート分配グラフの前、そして、現状の間で変遷に必要な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.

初期のRT会員資格交換が完全であるというヒントとして、実現SHOULDはRIBのEndマーカーを発生させます、[8]で定義されるように、Route Target会員資格(afi、safi)のために、優雅な再開がBGPセッションのときに可能にされるかどうかにかかわらず。 これは、それがいつ同輩の会員資格情報の完全なコンテンツを受けたかを知るために受信機を許容します。 VPN NLRIの交換はRIBのEndマーカーの領収書に続いて起こるべきです。

   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スピーカーが、このRIBのEndマーカーを受け取るまでBGP VPNルートアップデートの広告を遅らせるのを選ぶなら、それはその遅れを上限に制限しなければなりません。 デフォルトで、値がそうするべきである60秒に使用されてください。

Marques, et al.             Standards Track                     [Page 9]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[9ページ]

7.  Deployment Considerations

7. 展開問題

   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.

また、他のNLRIsに適切な同じ方針メカニズムも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.

例えば、コネ、相互、ケース、与えられたVPNはすべて参加しているASesの部分集合だけに接続されそうです。 マニュアルを通してVPNルート氾濫の範囲を制限する唯一の現在のメカニズムが、外部のBGPで境界ルータをフィルターにかけながら、あります。 現在の提案で、ダイナミックなRoute Target会員資格情報によると、そのようなフィルタリングを実行できます。

   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に使用されるすべてのRTsではなく、展開には、外部の意味があります。 例えば、VPNはaハブRTを使用できます、そして、aは内部的に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翻訳はローカルの実現決定であると考えられます。

Marques, et al.             Standards Track                    [Page 10]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[10ページ]

8.  Security Considerations

8. セキュリティ問題

   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ベースのVPNsのセキュリティの特性を変更しません。 しかしながら、RT会員資格情報NLRIsから組立てられた出力ルートフィルタがセキュリティ目的のために意図しないことに注意してください。 別々の管理ドメインの間でルーティング情報を交換するとき、RT会員資格情報に加えたある他の手段ですべての送受信のNLRIsをフィルターにかけるのは、良い習慣です。 また、実現SHOULDはRT会員資格情報をフィルターにかける手段を提供します。

9.  Acknowledgements

9. 承認

   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.

また、作者は彼らのコメントと提案についてヤコフRekhter、ダン・タッパン、デーヴ・ウォード、ジョンScudder、およびジェリーAshに感謝したがっています。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ベイツ、T.、チェン、E.、およびR.チャンドラ、「BGPは反射を発送します」。 「完全なメッシュ内部のBGP(IBGP)への代替手段」、RFC4456、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仮想私設網(VPNs)」、RFC4364 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)」、RFC4271 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.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」

   [6]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
        Communities Attribute", RFC 4360, February 2006.

[6] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。

Marques, et al.             Standards Track                    [Page 11]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[11ページ]

10.2.  Informative References

10.2. 有益な参照

   [7]  Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability
        for BGP-4", Work in Progress, December 2004.

[7] チェン、E.、およびY.Rekhterは「2004年12月にBGP-4インチ、処理中の作業のためにフィルタリング能力を協力して発送します」。

   [8]  Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen,
        "Graceful Restart Mechanism for BGP", Work in Progress, June
        2004.

[8] サーングリ、S.、Y.とフェルナンドとR.とScudder、J.とE.チェン、「BGPのための優雅な再開メカニズム」というRekhterは進行中(2004年6月)で働いています。

   [9]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work
        in Progress, April 2005.

[9] 「仮想の個人的なLANサービス」というKompella、K.、およびY.Rekhterは進歩、2005年4月に働いています。

   [10] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
        Private Network (VPN) Terminology", RFC 4026, March 2005.

[10] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。

Authors' Addresses

作者のアドレス

   Pedro Marques
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

ペドロ捕獲許可杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国

   EMail: roque@juniper.net

メール: roque@juniper.net

   Ronald Bonica
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

ロナルドBonica Juniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国

   EMail: rbonica@juniper.net

メール: rbonica@juniper.net

   Luyuan Fang
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   US

ビーバーブルック道路Boxborough、Luyuan牙のシスコシステムズInc.300MA01719米国

   EMail: lufang@cisco.com

メール: lufang@cisco.com

Marques, et al.             Standards Track                    [Page 12]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[12ページ]

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO  80112
   US

ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、Suite400イングルウッド、CO80112米国

   EMail: lmartini@cisco.com

メール: lmartini@cisco.com

   Robert Raszuk
   Cisco Systems, Inc.
   170 West Tasman Dr
   San Jose, CA  95134
   US

ロバートRaszukシスコシステムズInc.170の西タスマンサンノゼ博士、カリフォルニア95134米国

   EMail: rraszuk@cisco.com

メール: rraszuk@cisco.com

   Keyur Patel
   Cisco Systems, Inc.
   170 West Tasman Dr
   San Jose, CA  95134
   US

KeyurパテルシスコシステムズInc.170の西タスマンサンノゼ博士、カリフォルニア95134米国

   EMail: keyupate@cisco.com

メール: keyupate@cisco.com

   Jim Guichard
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA  01719
   US

ビーバーブルック道路Boxborough、ジムギシャールシスコシステムズInc.300MA01719米国

   EMail: jguichar@cisco.com

メール: jguichar@cisco.com

Marques, et al.             Standards Track                    [Page 13]

RFC 4684              Route Target (RT) Constrain          November 2006

捕獲許可、他 RFC4684ルート目標(RT)が2006年11月に抑制する標準化過程[13ページ]

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Marques, et al.             Standards Track                    [Page 14]

捕獲許可、他 標準化過程[14ページ]