Internet Engineering Task Force (IETF) P. Marques
Request for Comments: 6368
Category: Standards Track R. Raszuk
ISSN: 2070-1721 NTT MCL
K. Patel
Cisco Systems
K. Kumaki
T. Yamagata
KDDI Corporation
September 2011
Internal BGP as the Provider/Customer Edge Protocol for
BGP/MPLS IP Virtual Private Networks (VPNs)
Abstract
抽象
This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned.
この文書は、BGP / MPLS IP VPNの中BGPプロバイダ/カスタマーエッジルータの反復のためのプロトコルの拡張機能と手順を定義します。これらの拡張機能と手順は、ルーティング情報が懸念している限り、お客様のネットワークに透過的BGP / MPLS IP VPNの使用を作るという目的を持っています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6368.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6368で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. IP VPN as a Route Server ........................................3
4. Path Attributes .................................................5
5. BGP Customer Route Attributes ...................................6
6. Next-Hop Handling ...............................................7
7. Exchanging Routes between Different VPN Customer Networks .......8
8. Deployment Considerations ......................................10
9. Security Considerations ........................................12
10. IANA Considerations ...........................................12
11. Acknowledgments ...............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
In current deployments, when BGP is used as the Provider/Customer Edge routing protocol, these peering sessions are typically configured as an external peering between the VPN provider autonomous system (AS) and the customer network autonomous system. At each External BGP boundary, BGP path attributes [RFC4271] are modified as per standard BGP rules. This includes prepending the AS_PATH attribute with the autonomous-system number of the originating Customer Edge (CE) router and the autonomous-system number(s) of the Provider Edge (PE) router(s).
現在の展開では、BGPは、プロバイダ/カスタマエッジルーティングプロトコルとして使用される場合、これらのピアリングセッションは、典型的には、VPNプロバイダの自律システム（AS）と顧客ネットワークの自律システムとの間の外部ピアとして構成されています。各外部BGP境界で、BGPパスは[RFC4271]は、標準的なBGPルールに従って修正される属性。これは、元の顧客エッジ（CE）ルータの自律システム番号とプロバイダエッジ（PE）ルータ（複数可）の自律システム番号（複数可）とのAS_PATH属性を付加含みます。
In order for such routes not to be rejected by AS_PATH loop detection, a PE router advertising a route received from a remote PE often remaps the customer network autonomous-system number to its own. Otherwise, the customer network can use different autonomous-system numbers at different sites or configure their CE routers to accept routes containing their own AS number.
AS_PATHループ検出によって拒絶されないようなルートのために、リモートPEから受け取ったルートをアドバタイズPEルータは、多くの場合、独自の顧客ネットワークの自律システム番号をリマップします。そうでなければ、顧客ネットワークは異なる部位に異なる自律システム番号を使用するか、自分のAS番号を含むルートを受け入れるために彼らのCEルータを設定することができます。
While this technique works well in situations where there are no BGP routing exchanges between the client network and other networks, it does have drawbacks for customer networks that use BGP internally for purposes other than interaction between CE and PE routers.
この技術は、クライアントのネットワークと他のネットワークとの間にはBGPルーティング交換が存在しない状況ではうまく動作しますが、それは、CEとPEルータ間の相互作用以外の目的のために内部BGPを使用する顧客ネットワークのための欠点があります。
In order to make the usage of BGP/MPLS VPN services as transparent as possible to any external interaction, it is desirable to define a mechanism by which PE-CE routers can exchange BGP routes by means other than External BGP.
外部の相互作用にできるだけ透明にBGP / MPLS VPNサービスの利用を行うためには、PE-CEルータは、外部BGP以外の手段によってBGPルートを交換することができるメカニズムを定義することが望ましいです。
One can consider a BGP/MPLS VPN as a provider-managed backbone service interconnecting several customer-managed sites. While this model is not universal, it does constitute a good starting point.
一つは、いくつかの顧客管理のサイトを相互接続するプロバイダーが管理する基幹サービスとしてBGP / MPLS VPNを考慮することができます。このモデルは普遍的ではないですが、それは良い出発点を構成するものでもありません。
Independently of the presence of VPN service, networks often use a hierarchical design utilizing either BGP route reflection [RFC4456] or confederations [RFC5065]. This document assumes that the IP VPN service interacts with the customer network following a similar model.
独立して、VPNサービスの存在、ネットワークは、多くの場合、BGPルートリフレクション[RFC4456]または同盟[RFC5065]のいずれかを利用して、階層設計を使用します。この文書では、IP 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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
In a typical backbone/area hierarchical design, routers that attach an area (or site) to the core use BGP route reflection (or confederations) to distribute routes between the top-level core Internal BGP (iBGP) mesh and the local area iBGP cluster.
典型的なバックボーン/領域における階層設計、コア使用BGPルート反射（または連合）の領域（又はサイト）を取り付けるルータ最上位のコア内部BGP（iBGPの）メッシュとローカルエリアのiBGPクラスタ間のルートを分配します。
To provide equivalent functionality in a network using a provider-provisioned backbone, one can consider the VPN as the equivalent of an Internal BGP Route Server that multiplexes information from _N_ VPN attachment points.
プロバイダプロビジョニングバックボーンを使用して、ネットワーク内の同等の機能を提供するためには、_N_ VPN接続点から情報を多重内部BGPルートサーバと同等にVPNを考えることができます。
A route learned by any of the PEs in the IP VPN is available to all other PEs that import the Route Target used to identify the customer network. This is conceptually equivalent to a centralized route server.
IP VPN内のPEのいずれかによって学習ルートは、ルートターゲットは、顧客のネットワークを識別するために使用されるインポート他のすべてのPEに使用可能です。これは、中央集中型のルートサーバーに概念的に等価です。
In a PE router, PE-received routes are not advertised back to other PEs. It is this split-horizon technique that prevents routing loops in an IP VPN environment. This is also consistent with the behavior of a top-level mesh of route reflectors (RRs).
PEルータでは、PE-受信したルートは、他のPEに戻ってアドバタイズされません。これは、IP VPN環境でのルーティングループを防止し、このスプリットホライズン技法です。これはまた、ルートリフレクタの最上位メッシュ（RRS）の挙動と一致しています。
In order to complete the Route Server model, it is necessary to be able to transparently carry the Internal BGP path attributes of customer network routes through the BGP/MPLS VPN core. This is achieved by using a new BGP path attribute, described below, that allows the customer network attributes to be saved and restored at the BGP/MPLS VPN boundaries.
ルートサーバーモデルを完了するためには、透過内部BGPパスがBGP / MPLS VPNコアを介して顧客ネットワークの経路の属性を運ぶことができることが必要です。これは、顧客のネットワークが保存され、BGP / MPLS VPNの境界で復元することができます属性を以下で説明する新しいBGPパス属性を、使用することによって達成されます。
When a route is advertised from PE to CE, if it is advertised as an iBGP route, the CE will not advertise it further unless it is itself configured as a route reflector (or has an External BGP session). This is a consequence of the default BGP behavior of not advertising iBGP routes back to iBGP peers. This behavior is not modified.
ルートがPEからCEに通知されたときにそれがのiBGPルートとしてアドバタイズされた場合、それ自体がルートリフレクタとして構成された（または外部BGPセッションを有している）されていない限り、CEは、さらに、それをアドバタイズしないであろう。これは、iBGPピアに戻っiBGPルートをアドバタイズしないのデフォルトのBGPの行動の結果です。この動作は変更されません。
On a BGP/MPLS VPN PE, a CE-received route MUST be advertised to other VPN PEs that import the Route Targets that are associated with the route. This is independent of whether the CE route has been received as an external or internal route. However, a CE-received route is not re-advertised back to other CEs unless route reflection is explicitly configured. This is the equivalent of disabling client-to-client reflection in BGP route reflection implementations.
BGP / MPLS VPN PEに、CE-受信したルートは、ルートに関連付けられたルートターゲットをインポートする他のVPNのPEに通知しなければなりません。これは、CEルートは、外部または内部のルートとして受信されたかどうかとは無関係です。経路反射を明示的に設定されていない限りしかし、CE-受信した経路は、他のCEに戻って再アドバタイズされません。これは、BGPルート反射実装でクライアントからクライアントへの反射を無効にするのと等価です。
When reflection is configured on the PE router, with local CE routers as clients, there is no need to internally mesh multiple CEs that may exist in the site.
反射がPEルータ上で設定されている場合、クライアントとしてローカルCEルータで、内部サイト内に存在する可能性がある複数のCEをメッシュにする必要はありません。
This Route Server model can also be used to support a confederation-style abstraction to CE devices. At this point, we choose not to describe in detail the procedures for that mode of operation. Confederations are considered to be less common than route reflection in enterprise environments.
このルートサーバモデルは、CEデバイスに連合スタイルの抽象化をサポートするために使用することができます。この時点で、我々は、操作のそのモードのために詳細に手順を説明しないことを選択しました。同盟は、企業環境におけるルート反射未満一般的であると考えられます。
--> push path attributes --> vrf-export --> BGP/MPLS IP VPN VRF route PE-PE route advertisement <-- pop path attributes <-- vrf-import <--
- >プッシュパス属性 - > VRFエクスポート - > BGP / MPLS IP VPN VRFルートPE-PEルート広告< - ポップパスの属性< - VRF-インポート< -
The diagram above shows the BGP path attribute stack processing in relation to existing BGP/MPLS IP VPN [RFC4364] route processing procedures. BGP path attributes received from a customer network are pushed into the stack, before adding the Export Route Targets to the BGP path attributes. Conversely, the stack is popped following the Import Target processing step that identifies the VPN Routing and Forwarding (VRF) table in which a PE-received route is accepted.
上記の図は、既存のBGP / MPLS VPN IP [RFC4364]経路処理手順に関してBGPパス属性スタック処理を示しています。 BGPパスは、顧客ネットワークから受信した属性は、BGPパス属性にエクスポートルートターゲットを追加する前に、スタックにプッシュされます。逆に、スタックは、PE-受信した経路が受け付けられたVPNルーティングおよび転送（VRF）テーブルを識別するインポートターゲット処理工程の後ポップされます。
When the advertising PE performs a "push" operation at the "vrf-export" processing stage, it SHOULD initialize the attributes of the BGP IP VPN route advertisement as it would for a locally originated route from the respective VRF context.
広告PEは「VRFエクスポート」処理段階で「プッシュ」操作を行うと、それがローカルに各VRFコンテキストからルートを発信するために同じようにBGP IP VPNの経路広告の属性を初期化する必要があります。
When a PE-received route is imported into a VRF, its IGP metric, as far as BGP path selection is concerned, SHOULD be the metric to the remote PE address, expressed in terms of the service provider metric domain.
PE-受信したルートをVRFにインポートされると、そのIGPメトリックは、限りBGPパス選択に関しては、リモートPEアドレスにメトリックされるべきであり、サービスプロバイダメトリックドメインで表現。
For the purposes of VRF route selection performed at the PE, between routes received from local CEs and remote PEs, customer network IGP metrics SHOULD always be considered higher (and thus least preferred) than local site metrics.
ローカルCEとリモートのPEから受け取ったルート間PEで行わVRF経路選択の目的のために、顧客のネットワークのIGPメトリックは常にローカルサイトメトリックよりも高い（したがって最も好ましい）を考慮すべきです。
When backdoor links are present, this would tend to direct the traffic between two sites through the backdoor link for BGP routes originated by a remote site. However, BGP already has policy mechanisms, such as the LOCAL_PREF attribute, to address this type of situation.
バックドアリンクが存在する場合、これは、リモートサイトから発信BGPルートのバックドアリンクを介して2つのサイト間のトラフィックを指示する傾向があります。しかし、BGPは、すでにこの種の状況に対処するために、このようLOCAL_PREF属性としてポリシーメカニズムを持っています。
When a given CE is connected to more than one PE, it will not advertise the route that it receives from a PE to another PE unless configured as a route reflector, due to the standard BGP route advertisement rules.
所与のCEは、複数のPEに接続されている場合、それが原因標準BGPルート広告ルールに、ルートリフレクタとして構成されていない限り、それはPEから別のPEに受信したルートをアドバタイズしないであろう。
When a CE reflects a PE-received route to another PE, the fact that the original attributes of a route are preserved across the VPN prevents the formation of routing loops due to mutual redistribution between the two networks.
CEは、別のPEにPE-受信した経路を反映する場合、経路の元の属性はVPNを横切って保存されているという事実は、2つのネットワーク間の相互再分配にルーティングループの形成を防止します。
In order to transparently carry the BGP path attributes of customer routes, this document defines a new BGP path attribute:
透過的に顧客ルートのBGPパス属性を実行するためには、この文書は、新しいBGPパス属性を定義します。
ATTR_SET (type code 128)
ATTR_SET（種別コード128）
ATTR_SET is an optional transitive attribute that carries a set of BGP path attributes. An attribute set (ATTR_SET) can include any BGP attribute that can occur in a BGP UPDATE message, except for the MP_REACH and MP_UNREACH attributes.
ATTR_SETは、BGPパス属性のセットを運ぶオプションの推移属性です。属性セット（ATTR_SET）はMP_REACHとMP_UNREACH属性を除いて、BGPアップデートメッセージで発生することができる任意のBGP属性を含むことができます。
The ATTR_SET attribute is encoded as follows:
次のようにATTR_SET属性はエンコードされています。
+------------------------------+
| Attr Flags (O|T) Code = 128 |
+------------------------------+
| Attr. Length (1 or 2 octets) |
+------------------------------+
| Origin AS (4 octets) |
+------------------------------+
| Path Attributes (variable) |
+------------------------------+
The Attribute Flags are encoded according to RFC 4271 [RFC4271]. The Extended Length bit determines whether the Attribute Length is one or two octets.
属性フラグは、RFC 4271 [RFC4271]に従って符号化されます。拡張長さビットは、属性の長さは、1つのまたは2つのオクテットであるか否かを判断します。
The attribute value consists of a 4-octet "Origin AS" value followed by a variable-length field that conforms to the BGP UPDATE message path attribute encoding rules. The length of this attribute is 4 plus the total length of the encoded attributes.
属性値は、ルールをコードするBGP UPDATEメッセージのパス属性に準拠可変長フィールドに続く値「起源」4オクテットで構成されています。この属性の長さは4プラスエンコードされた属性の合計の長さです。
The ATTR_SET attribute is used by a PE router to store the original set of BGP attributes it receives from a CE. When a PE router advertises a PE-received route to a CE, it will use the path attributes carried in the ATTR_SET attribute.
ATTR_SET属性はBGPの元のセットは、それがCEから受信した属性を記憶するためにPEルータによって使用されます。 PEルータは、CEへのPE-受信した経路を広告する場合、それはATTR_SET属性で運ばれたパス属性を使用します。
In other words, the BGP path attributes are "pushed" into this attribute, which operates as a stack, when the route is received by the VPN and "popped" when the route is advertised in the PE-to-CE direction.
換言すれば、BGPパス属性は、ルートがPE対CE方向にアドバタイズされたときにルートがVPNや「ポップ」で受信した場合、スタックとして動作し、この属性に「プッシュ」されます。
Using this mechanism isolates the customer network from the attributes used in the customer network and vice versa. Attributes such as the route reflection cluster list attribute are segregated such that customer network cluster identifiers won't be considered by the customer network route reflectors and vice versa.
このメカニズムを使用することで、顧客のネットワークとその逆で使用される属性からの顧客ネットワークを分離します。そのような経路の反射クラスタリスト属性などの属性は、顧客ネットワーククラスタ識別子は、顧客ネットワークルートリフレクタおよびその逆によって考慮されないこと偏析なものです。
The Origin autonomous-system number is designed to prevent a route originating in a given autonomous-system iBGP from being leaked into a different autonomous system without proper AS_PATH manipulation. It SHOULD contain the autonomous-system number of the customer network that originates the given set of attributes. The value is encoded as a 32-bit unsigned integer in network byte order, regardless of whether or not the originating PE supports 4-octet AS numbers [RFC4893].
オリジン自律システム番号は、適切AS_PATH操作することなく、異なる自律システムに漏れることから与えられる自律システムのiBGPに由来する経路を防止するように設計されています。これは、属性のセットを発信し、顧客のネットワークの自律システム番号を含むべきです。値に関係なく、発信PEが番号[RFC4893]と4オクテットをサポートしているか否かを、ネットワークバイト順で32ビットの符号なし整数として符号化されます。
The AS_PATH and AGGREGATOR attributes contained within an ATTR_SET attribute MUST be encoded using 4-octet AS numbers [RFC4893], regardless of the capabilities advertised by the BGP speaker to which the ATTR_SET attribute is transmitted. BGP speakers that support the extensions defined in this document MUST also support RFC 4893 [RFC4893]. The reason for this requirement is to remove ambiguity between 2-octet and 4-octet AS_PATH attribute encoding.
ATTR_SET属性内に含まAS_PATHとAGGREGATOR属性は4オクテット番号[RFC4893] ASに関わらず、BGPスピーカによってアドバタイズ機能のATTR_SET属性を送信するためにを使用して符号化されなければなりません。この文書で定義された拡張をサポートするBGPスピーカはまた、RFC 4893 [RFC4893]をサポートしなければなりません。この要件の理由は、2オクテット及び4オクテットのAS_PATH属性のエンコーディングの間の曖昧さを除去することです。
The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. When present, it SHOULD be ignored by the receiving PE. Future applications of the ATTR_SET attribute MAY define meaningful semantics for an included NEXT_HOP attribute.
NEXT_HOP属性はATTR_SETに含めるべきではありません。存在する場合、それは受信PEによって無視されるべきです。 ATTR_SET属性の将来のアプリケーションが含まNEXT_HOP属性の意味の意味を定義するかもしれません。
The ATTR_SET attribute SHALL be considered malformed if any of the following apply:
次のいずれかに該当する場合ATTR_SET属性が不正な形式の考慮しなければなりません。
o Its length is less than 4 octets.
Oその長さは4つのオクテット未満です。
o The original path attributes carried in the variable-length attribute data include the MP_REACH or MP_UNREACH attribute.
元のパスは、可変長の属性データで運ば属性oをMP_REACH又はMP_UNREACH属性を含みます。
o The included attributes are malformed themselves.
O含ま属性自体を不正な形式です。
An UPDATE message with a malformed ATTR_SET attribute SHALL be handled as follows. If its Partial flag is set and its Neighbor-Complete flag is clear, the UPDATE is treated as a route withdraw as discussed in [OPT-TRANS-BGP]. Otherwise (i.e., Partial flag is clear or Neighbor-Complete is set), the procedures of the BGP-4 base specification [RFC4271] MUST be followed with respect to an Optional Attribute Error.
次のように不正な形式のATTR_SET属性を持つUPDATEメッセージが処理されるものとします。その部分フラグが設定され、その隣接-完了フラグがクリアされた場合、アップデート[OPT-TRANS-BGP]で議論するように経路が撤回として扱われます。そうでない場合（すなわち、パーシャルフラグがクリアまたは近隣一式である）、BGP-4ベースの仕様[RFC4271]の手順は、オプションの属性エラーに対して従わなければなりません。
When BGP/MPLS VPNs are not in use, the NEXT_HOP attribute in iBGP routes carries the address of the border router advertising the route into the domain. The IGP distance to the NEXT_HOP of the route is an important component of BGP route selection.
BGP / MPLS VPNのが使用されていない場合は、iBGPルートでNEXT_HOP属性は、ドメインにルートをアドバタイズする境界ルータのアドレスを運びます。ルートのNEXT_HOPにIGP距離は、BGPルート選択の重要な構成要素です。
When a BGP/MPLS VPN service is used to provide interconnection between different sites, since the customer network runs a different IGP domain, metrics between the provider and customer networks are not comparable.
BGP / MPLS VPNサービスは、顧客のネットワークが異なるIGPドメインを実行しているため、異なるサイト間の相互接続を提供するために使用された場合は、プロバイダと顧客ネットワーク間のメトリックを比較することはできません。
However, the most important component of a metric is the inter-area metric, which is known to the customer network. The intra-area metric is typically negligible.
しかし、メトリックの最も重要な要素は、顧客のネットワークに知られているエリア間のメトリック、です。エリア内のメトリックは、典型的には無視できます。
The use of route reflection, for instance, requires metrics to be configured so that inter-cluster/area metrics are always greater than intra-cluster metrics.
経路反射の使用は、例えば、クラスタ間/面積メトリックは、クラスタ内のメトリックよりも常に大きくなるように設定するメトリックを必要とします。
The approach taken by this document is to rewrite the NEXT_HOP attribute at the VRF import/export boundary. PE routers take into account the PE-PE IGP distance calculated by the customer network IGP, when selecting between routes advertised from different PEs.
このドキュメントで撮影したアプローチは、VRFのインポート/エクスポートの境界でNEXT_HOP属性を書き換えることです。別のPEからアドバタイズされたルートの間に選択するときPEルータは、アカウントに顧客ネットワークIGPによって算出PE-PE IGP距離を取ります。
An advantage of the proposed method is that the customer network can run independent IGPs at each site.
提案手法の利点は、顧客のネットワークが各サイトで独立したのIGPを実行することができるということです。
In the traditional model, where External BGP sessions are used between the BGP/MPLS VPN PE and CE, the PE router identifies itself as belonging to the customer network autonomous system.
外部BGPセッションがBGP / MPLS VPN PEとCEの間で使用される伝統的なモデルでは、PEルータは、顧客ネットワークの自律システムに属するものとして自分自身を識別する。
In order to use Internal BGP sessions, the PE router has to identify itself as belonging to the customer AS. More specifically, the VRF that is used to interconnect to that customer site is assigned to the customer AS rather than the VPN provider AS.
内部BGPセッションを使用するためには、PEルータはASの顧客に属するものとして自分自身を識別することがあります。具体的には、その顧客のサイトに相互接続するために使用されるVRFは、顧客としてではなく、AS VPNプロバイダに割り当てられています。
The Origin AS element in the ATTR_SET path attribute conveys the AS number of the originating VRF. This AS number is used in a receiving PE in order to identify route exchanges between VRFs in different ASes.
ATTR_SETパス属性における原点としての要素は、元のVRFのAS番号を伝えます。このAS番号が異なるのAS内のVRF間の経路交換を識別するために、受信PEに使用されます。
In scenarios such as what is commonly referred to as an "extranet" VPN, routes MAY be advertised to both internal and external VPN attachments belonging to different autonomous systems.
そのような一般に「エクストラネット」VPNと呼ばれるもののようなシナリオでは、経路は、異なる自律システムに属する内部と外部の両方のVPNの添付ファイルにアドバタイズされるかもしれません。
+-----+ +-----+
| PE1 |-----------------| PE2 |
+-----+ +-----+
/ \ |
+-----+ +-----+ +-----+
| CE1 | | CE2 | | CE3 |
+-----+ +-----+ +-----+
AS 1 AS 2 AS 1
Consider the example given above, where (PE1, CE1) and (PE2, CE3) sessions are iBGP. In BGP/MPLS VPNs, a route received from CE1 above may be distributed to the VRFs corresponding to the attachment points for CEs 2 and 3.
上記の例、（PE1、CE1）および（PE2、CE3）セッションを考えるのiBGPあります。 BGP / MPLS VPNの中で、上記CE1から受信した経路は、複数のCE 2および3のアタッチメントポイントに対応するのVRFに分配されてもよいです。
The desired result in such a scenario is to present the internal peer (CE3) with a BGP advertisement that contains the same BGP path attributes received from CE1, and to present the external peer (CE2) with a BGP advertisement that would correspond to a situation where AS 1 and AS 2 have an External BGP session between them.
このようなシナリオでは、所望の結果は、同じBGPパスがCE1から受信した属性が含まBGPの広告に内部ピア（CE3）を提示し、そして状況に対応するBGPの広告に外部ピア（CE2）を提示することです1 ASおよび2として、それらの間に外部BGPセッションを持っています。
In order to achieve this goal, the following set of rules applies:
この目標を達成するために、以下のルールのセットが適用されます。
When importing a VPN route that contains the ATTR_SET attribute into a destination VRF, a PE router MUST check that the "Origin AS" number contained in the ATTR_SET attribute matches the autonomous system associated with the VRF.
先VRFにATTR_SET属性が含まれているVPNルートをインポートする場合、PEルータはATTR_SET属性に含まれている番号「AS起源は、」VRFに関連付けられた自律システムと一致していることをチェックしなければなりません。
In case the autonomous-system numbers do match, the route is imported into the VRF with the attributes contained in the ATTR_SET attribute. Otherwise, in the case of an autonomous-system number mismatch, the set of attributes to be associated with the route SHALL be constructed as follows:
場合には自律システム番号が一致しない、ルートがATTR_SET属性に含まれる属性でVRFにインポートされます。次のようにそうでなければ、自律システム番号の不一致の場合には、ルートに関連する属性のセットを構築しなければなりません：
1. The path attributes are set to the attributes contained in the ATTR_SET attribute.
1.パス属性はATTR_SET属性に含まれる属性に設定されています。
2. iBGP-specific attributes are discarded (LOCAL_PREF, ORIGINATOR, CLUSTER_LIST, etc).
2. iBGPの固有の属性は（LOCAL_PREF、ORIGINATOR、CLUSTER_LISTなど）廃棄されます。
3. The "Origin AS" number contained in the ATTR_SET attribute is prepended to the AS_PATH following the rules that would apply to an External BGP peering between the source and destination ASes.
3. ATTR_SET属性に含ま番号「AS起源は、」外部BGPは、送信元と宛先のAS間のピアリングに適用される規則を以下のAS_PATHの前に付加されます。
4. If the autonomous system associated with the VRF is the same as the VPN provider autonomous system and the AS_PATH attribute of the VPN route is not empty, it SHALL be prepended to the AS_PATH attribute of the VRF route.
4. VRFに関連付けられた自律システムは、VPNプロバイダ自律システムと同じで、VPNルートのAS_PATH属性が空でない場合、それはVRFルートのAS_PATH属性の前に追加されるものとします。
When advertising the VRF route to an External BGP peer, a PE router SHALL apply steps 1 to 4 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute. For example, if the route originated in a VRF that supports Internal BGP peering and the ATTR_SET attribute and is advertised to a CE that is configured in the traditional External BGP mode, then the originator AS, the VPN AS_PATH segment, and the customer network AS are prepended to the AS_PATH.
外部BGPピアにVRFルートをアドバタイズするとき、PEルータは、上記で定義され、その後、AS_PATH属性にそれ自身の自律システム番号を付加4のステップ1を適用しなければなりません。たとえば、ルートは、VPNのAS_PATHセグメント、AS創始者、および顧客のネットワークとして、内部BGPピアリングとATTR_SET属性と伝統的な外部BGPモードに設定されているCEにアドバタイズされるサポートVRF発祥の場合AS_PATHの前に付加されています。
When importing a route without the ATTR_SET attribute to a VRF that is configured in a different autonomous system, a PE router MUST prepend the VPN provider AS number to the AS_PATH.
異なる自律システムで構成されているVRFにATTR_SET属性を持たないルートをインポートする場合、PEルータはAS_PATHのAS番号VPNプロバイダを付加しなければなりません。
In all cases where a route containing the ATTR_SET attribute is imported, attributes present on the VPN route other than the NEXT_HOP attribute are ignored, both from the point of view of route selection in the VRF Adj-RIB-In and route advertisement to a CE router. In other words, the information contained in the ATTR_SET attribute overrides the VPN route attributes on "vrf-import".
ATTR_SET属性を含むルートがインポートされるすべての場合において、CEのVRFのAdj-RIB-においてにおける経路選択のビュー及びルート広告のポイントの両方から、無視さNEXT_HOP属性以外のVPNの経路上に存在する属性ルータ。言い換えれば、ATTR_SET属性に含まれる情報は、VPNルートは、「VRF-インポート」の属性よりも優先されます。
It is RECOMMENDED that different VRFs of the same VPN (i.e., in different PE routers) that are configured with iBGP PE-CE peering sessions use different Route Distinguisher (RD) values. Otherwise (in the case where the same RD is used), the BGP IP VPN infrastructure may select a single BGP customer path for a given IP Network Layer Reachability Information (NLRI) without access to the detailed path information that is contained in the ATTR_SET attribute.
iBGPのPE-CEピアリング・セッションで構成されている（異なるPEルータで、すなわち、）同じVPNの異なるVRFは、異なるルート識別子（RD）値を使用することをお勧めします。そうでない場合（同じRDを使用している場合）、BGP IP VPNインフラストラクチャはATTR_SET属性に含まれている詳細なパス情報にアクセスすることなく与えられたIPネットワーク層到達可能性情報（NLRI）のための単一のBGP顧客のパスを選択することができ。
As mentioned previously, the model for this service is a "Route Server" where the IP VPN provides the customer network with all the BGP paths known by the CEs. This effectively implies the use of unique RDs per VRF.
前述したように、このサービスのためのモデルでは、IP VPNは、のCEで知られているすべてのBGPパスを顧客ネットワークを提供する「ルートサーバ」です。これは、効果的にVRFごとに一意のRDを使用することを意味します。
The stated goal of this extension is to isolate the customer network from the BGP path attribute operations performed by the IP VPN and conversely isolate the service provider network from any attributes injected by the customer. For instance, BGP communities can be used to influence the behavior of the IP VPN infrastructure. Using this extension, the service provider network can transparently carry these attributes without interfering with its operations.
この拡張機能の述べた目標は、BGPパスからお客様のネットワークを隔離IP VPNの動作を属性と逆に顧客が注入された任意の属性からサービスプロバイダのネットワークを分離することです。例えば、BGPコミュニティは、IP VPNインフラストラクチャの動作に影響を与えるために使用することができます。この拡張機能を使用して、サービスプロバイダーネットワークは、透過的にその業務を妨害することなく、これらの属性を運ぶことができます。
Another example of unwanted interaction between customer and IP VPN BGP attributes is a scenario where the same service provider autonomous-system number is used to provide Internet service as well as the IP VPN service. In this case, it is not uncommon to have a VPN customer route contain the AS number of the service provider. The IP VPN should work transparently in this case as in all others.
顧客およびIP VPN BGP属性間の望ましくない相互作用の別の例は、同じサービスプロバイダ自律システム番号は、インターネットサービスだけでなく、IP VPNサービスを提供するために使用されるシナリオです。この場合、VPNの顧客ルートは、サービスプロバイダのAS番号を含む持つことは珍しいことではありません。 IP VPNは、他のすべてのように、この場合には透過的に動作するはずです。
This protocol extension is designed to behave such that each PE VRF operates as a router in the configured AS. Previously, VRFs operated in the provider network AS only. The VPN backbone provides interconnection between VRFs of the same AS, as well as interconnection between different ASes (subject to the appropriate policies). When interconnecting VRFs in the same AS, the VPN backbone operates as a top-level route reflection mesh. When interconnecting VRFs in different ASes, the provider network provides an implicit peering relationship between the ASes that originate and import a specific route.
このプロトコル拡張は、各PE VRFが設定AS内のルータとして動作するように動作するように設計されています。以前は、VRFはASのみ、プロバイダのネットワークで動作しました。 VPNバックボーンは、同じASのVRF間の相互接続、ならびに別のAS（適切なポリシーに従う）との間の相互接続を提供します。同じASにVRFを相互接続する場合、VPNバックボーンは、最上位のルート反射メッシュとして動作します。別のAS内のVRFを相互接続する場合、プロバイダ・ネットワークは、特定のルートを発信し、インポートAS間の暗黙的なピアリング関係を提供します。
This extension is also applicable to scenarios where the VPN backbone spans multiple ASes. When the VPN backbone Inter-AS operation follows option b) or c) as defined in Section 10 of [RFC4364], the provider networks are able to influence the route attributes and route selection of the VPN routes while providing a transparent service to the customer AS. Either Internal BGP connectivity or extranets can be provided to the customer AS.
この拡張はまた、VPNバックボーンは、複数のASにまたがるシナリオに適用されます。 VPNバックボーンインターAS動作はオプションBを以下の場合）またはc）[RFC4364]のセクション10で定義されるように、プロバイダ・ネットワークは、顧客に透明なサービスを提供しながら、VPNルートのルート属性及びルート選択に影響を与えることが可能ですなので。内部BGP接続またはエクストラネットのどちらかを、顧客に提供することができます。
When VPN provider networks interconnect via option a), there is no possibility of providing a fully transparent service. By definition, option a) implies that each autonomous-system border router (ASBR) has a VRF associated with the customer VPN that is configured to operate in the respective provider AS. These ASBR VRFs then communicate via External BGP with their peer provider ASes.
オプションAを介してVPNプロバイダネットワーク相互接続）は、完全に透明なサービスを提供する可能性がない場合。定義では、オプションa）は、各自律システム境界ルータ（ASBR）はASそれぞれのプロバイダで動作するように構成され、顧客のVPNに関連付けられたVRFを持っていることを意味します。これらのASBR VRFはその後、彼らのピア・プロバイダのASと外部BGPを介して通信します。
In this case, it is still possible to have all the customer VRFs with one provider network be configured in the same customer AS. This customer AS will then peer with the provider AS implicitly at the ASBR, which will in turn peer explicitly with a second provider AS. This is not, however, a scenario in which transparency to the customer AS is possible.
この場合、1つのプロバイダのネットワークがAS同じ顧客に設定することで、すべての顧客のVRFを持つことも可能です。 AS、この顧客は、ASBRでAS暗黙的プロバイダとピアなるであろうように、第2のプロバイダで明示的にターンピアインチこれは、しかし、可能であるなど、顧客にその透明性シナリオではありません。
It is worthwhile to consider the security implications of this proposal from two independent perspectives: the IP VPN provider and the IP VPN customer.
IP VPNプロバイダとIP VPNの顧客：2つの独立した視点からこの提案のセキュリティへの影響を検討する価値があります。
From an IP VPN provider perspective, this mechanism will assure separation between the BGP path attributes advertised by the CE router and the BGP attributes used within the provider network, thus potentially improving security.
IP VPNプロバイダの観点から、この機構は、BGP経路の間の分離を保証するCEルータによってアドバタイズされた属性とBGP属性、したがって、潜在的にセキュリティを向上させる、プロバイダ・ネットワーク内で使用されます。
Although this behavior is largely implementation dependent, it is currently possible for a CE device to inject BGP attributes (extended communities, for example) that have semantics on the IP VPN provider network, unless explicitly disabled by configuration in the PE.
この動作は、大部分が実装に依存するが、明示的にPE内の設定で無効にしない限り、BGPを注入するCEデバイスは、IP VPNプロバイダーネットワーク上の意味を持っている（例えば、拡張コミュニティを、）属性の現在可能です。
With the rules specified for the ATTR_SET path attribute, any attribute that has been received from a CE is pushed into the stack before the route is advertised to other PEs.
ルートが他のPEにアドバタイズされる前ATTR_SETパス属性に指定された規則と、CEから受信された任意の属性は、スタックにプッシュされます。
As with any other field based on values received from an external system, an implementation must consider the issues of input validation and resource management.
外部システムから受け取った値に基づいて、他のフィールドと同じように、実装は、入力検証とリソース管理の問題を考慮しなければなりません。
From the perspective of the VPN customer network, it is our opinion that there is no change to the security profile of PE-CE interaction. While having an iBGP session allows the PE to specify additional attributes not allowed on an External BGP session (e.g., LOCAL_PREF), this does not significantly change the fact that the VPN customer must trust its service provider to provide it with correct routing information.
VPNの顧客ネットワークの観点からは、PE-CEのインタラクションのセキュリティプロファイルに変更がないことを私たちの意見です。 iBGPセッションを有するPEは、外部BGPセッション（例えば、LOCAL_PREF）で許可されていない追加の属性を指定することができますが、これは大幅にVPNの顧客が正しいルーティング情報とそれを提供するために、そのサービスプロバイダを信頼しなければならないという事実は変わりません。
This document defines a new BGP path attribute that is part of a registry space managed by IANA. IANA has updated its BGP Path Attributes registry with the value specified above (128) for the ATTR_SET path attribute.
この文書は、IANAによって管理されるレジストリ領域の一部である新しいBGPパス属性を定義します。 IANAはそのBGPパスがATTR_SETパス属性の（128）上で指定した値でレジストリを属性更新しました。
The authors would like to thank Stephane Litkowski and Bruno Decraene for their comments.
作者は彼らのコメントのためのステファンLitkowskiとブルーノDecraeneに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[RFC4456]ベイツ、T.、チェン、E.、およびR.チャンドラ、 "BGPルートリフレクション：フルメッシュ内部BGP（IBGP）への代替"、RFC 4456、2006年4月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893] Vohra著、Q.およびE.チェン、 "ナンバースペースAS 4オクテットのためのBGPのサポート"、RFC 4893、2007年5月。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007.
[RFC5065] Trainaの、P.、マクファーソン、D.、およびJ.スカダー、 "BGPのための自律システムコンフェデレーション"、RFC 5065、2007年8月。
[OPT-TRANS-BGP] Scudder, J. and E. Chen, "Error Handling for Optional Transitive BGP Attributes", Work in Progress, September 2010.
[OPT-TRANS-BGP]スカダー、J.およびE.チェン、 "オプションの推移BGP属性のエラー処理"、進歩、2010年9月に作業。
Authors' Addresses
著者のアドレス
Pedro Marques
ペドロ・マルケス
EMail: pedro.r.marques@gmail.com
メールアドレス：pedro.r.marques@gmail.com
Robert Raszuk NTT MCL 101 S. Ellsworth Avenue Suite 350 San Mateo, CA 94401 US
ロバートRaszuk NTT MCL 101 S.エルズワースアベニュースイート350サンマテオ、カリフォルニア州94401米国
EMail: robert@raszuk.net
メールアドレス：robert@raszuk.net
Keyur Patel Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
Keyurパテルシスコシステムズ170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
EMail: keyupate@cisco.com
メールアドレス：keyupate@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし ちよだーく、 ときょ １０２ー８４６０ じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com
Tomohiro Yamagata KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
ともひろ やまがた Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし ちよだーく、 ときょ １０２ー８４６０ じゃぱん
EMail: to-yamagata@kddi.com
メールアドレス：to-yamagata@kddi.com