[要約] RFC 5195は、レイヤー1 VPNのためのBGPベースの自動検出に関するものであり、レイヤー1 VPNの自動検出と設定を可能にするためのプロトコルを提案しています。目的は、ネットワークオペレーターが効率的にレイヤー1 VPNを管理できるようにすることです。
Network Working Group H. Ould-Brahim
Request for Comments: 5195 D. Fedyk
Category: Standards Track Nortel
Y. Rekhter
Juniper Networks
June 2008
BGP-Based Auto-Discovery for Layer-1 VPNs
Layer-1 VPNSのBGPベースの自動ディスコーブリー
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
このドキュメントの目的は、レイヤー-1 VPN（L1VPNS）のBGPベースの自動発見メカニズムを定義することです。L1VPNSの自動発見メカニズムにより、プロバイダーネットワークデバイスは、同じVPNの顧客エッジ（CE）メンバーにポートが接続されているプロバイダーエッジ（PES）のセットを動的に発見できます。この情報は、L1VPN接続のシグナルフェーズを完了するために必要です。L1VPNオートディスコバイのメカニズムの主な目的の1つは、「シングルエンドプロビジョニング」モデルをサポートすることです。特定のL1VPNに新しいポートを追加するには、このポートを持つPEとCEでのみ構成変更が含まれます。このポートを介してPEに接続します。
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK]. The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of PEs having ports attached to CE members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
このドキュメントの目的は、レイヤー1 VPN（L1VPNS）[L1VPN-FRMK]のBGPベースの自動発見メカニズムを定義することです。L1VPNSの自動発見メカニズムにより、プロバイダーネットワークデバイスは、同じVPNのCEメンバーにポートが接続されているPESのセットを動的に発見できます。この情報は、L1VPN接続のシグナルフェーズを完了するために必要です。L1VPNオートディスコバイのメカニズムの主な目的の1つは、「シングルエンドプロビジョニング」モデルをサポートすることです。特定のL1VPNに新しいポートを追加するには、このポートを持つPEとCEでのみ構成変更が含まれます。このポートを介してPEに接続します。
The auto-discovery mechanism proceeds by having a PE advertise to other PEs the following information, at a minimum: its own IP address and the list of <private address, provider address> tuples local to that PE. Once that information is received, the remote PEs will identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to perform address resolution during the signaling phase of Layer-1 VPN connections.
自動発見メカニズムは、PEが他のPEに次の情報を宣伝することで進行します。少なくとも、独自のIPアドレスと<プライベートアドレスのリスト、プロバイダーアドレス>そのPEにローカルなTuppleです。その情報が受信されると、リモートPEは広告PEと共通しているVPNメンバーのリストを特定し、レイヤー1 VPN接続のシグナル伝達段階でディスカバリーメカニズム内で携帯する情報を使用してアドレス解像度を実行します。
Figure 1 highlights the network reference for using a BGP-based auto-discovery mechanism for Layer-1 VPNs. For the purpose of the auto-discovery mechanism, BGP is running only on the provider network. The PEs maintain per-VPN information tables called Port Information Tables (PITs) related to <private address, provider address> information. More information on the PITs is in Section 2.
図1は、レイヤー-1 VPNにBGPベースの自動発見メカニズムを使用するためのネットワーク参照を強調しています。自動配置メカニズムの目的のために、BGPはプロバイダーネットワークでのみ実行されています。PESは、<プライベートアドレス、プロバイダーアドレス>情報に関連するポート情報テーブル（PITS）と呼ばれるVPNごとの情報表を維持します。ピットの詳細については、セクション2にあります。
PE1 PE2
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1: BGP Auto-Discovery for L1VPN
図1：L1VPNのBGPオートディスコーブリー
[L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic mode and the enhanced mode. This document describes an auto-discovery mechanism for the basic mode only.
[L1VPN-FRMK]は、L1VPNの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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In the context of L1VPNs, a CE is connected to a PE via one or more ports, where each port may consist of one or more channels or sub-channels. Each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). We refer to this identifier as the customer port identifier (CPI). Each port on a PE also has an identifier that is unique within the provider network. We refer to this identifier as the provider port identifier (PPI). Note that IP addresses used for CPIs or PPIs could be either IPv4 or IPv6 addresses.
L1VPNSのコンテキストでは、CEは1つ以上のポートを介してPEに接続され、各ポートは1つ以上のチャネルまたはサブチャネルで構成されます。CEをPEに接続するCEの各ポートには、そのL1VPN内で一意の識別子があります（ただし、いくつかのL1VPNで一意である必要はありません）。この識別子を顧客ポート識別子（CPI）と呼びます。PEの各ポートには、プロバイダーネットワーク内で一意の識別子もあります。この識別子をプロバイダーポート識別子（PPI）と呼びます。CPIまたはPPIに使用されるIPアドレスは、IPv4またはIPv6アドレスのいずれかである可能性があることに注意してください。
For each L1VPN that has at least one port configured on a PE, the PE maintains a Port Information Table (PIT). A PIT contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. Note that a PIT may also hold routing information (for example, when CPIs are learnt using a routing protocol).
PEで少なくとも1つのポートが構成されている各L1VPNについて、PEはポート情報テーブル（PIT）を維持します。ピットには、L1VPN内のすべてのポートの<CPI、PPI> Tulpleのリストが含まれています。ピットにはルーティング情報も保持される場合があることに注意してください（たとえば、ルーティングプロトコルを使用してCPIが学習された場合）。
A PIT on a given PE is populated with two types of information.
特定のPEのピットには、2種類の情報が入力されています。
- Information related to the CEs' ports attached to the ports on the PE. This information could be locally configured at the PE or could be received from the CEs.
- PEのポートに接続されたCESのポートに関連する情報。この情報は、PEでローカルで構成されているか、CESから受信することができます。
- Information received from other PEs through the auto-discovery mechanism.
- 自動発見メカニズムを通じて他のPESから受け取った情報。
We refer to the former as local information, and to the latter as remote information. Propagation of local information to other PEs is accomplished by using BGP multiprotocol extensions [RFC4760]. To restrict the flow of this information to only the PITs within a given L1VPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows.
前者をローカル情報と呼び、後者をリモート情報と呼びます。他のPESへのローカル情報の伝播は、BGPマルチプロトコル拡張[RFC4760]を使用して達成されます。この情報のフローを特定のL1VPN内のピットのみに制限するために、次のように、ルートターゲット拡張コミュニティ[BGP-COMM]に基づいてBGPルートフィルタリングを使用します。
Each PIT on a PE is configured with one or more Route Target Communities, called "export Route Targets", that are used for tagging the local information when it is exported into the provider's BGP. The granularity of such tagging could be as fine as a single <CPI, PPI> pair. In addition, each PIT on a PE is configured (at provisioning time) with one or more Route Target Communities, called "import Route Targets", that restrict the set of routes that could be imported from provider's BGP into the PIT to only the routes that have at least one of these Communities.
PE上の各ピットは、プロバイダーのBGPにエクスポートされるときにローカル情報のタグを付けるために使用される「エクスポートルートターゲット」と呼ばれる1つ以上のルートターゲットコミュニティで構成されています。このようなタグ付けの粒度は、単一の<cpi、ppi>ペアと同じくらい素晴らしい場合があります。さらに、PEの各ピットは、「ルートターゲットを輸入する」と呼ばれる1つ以上のルートターゲットコミュニティで（プロビジョニング時に）構成され、プロバイダーのBGPからピットにインポートできるルートのセットをルートのみに制限します。これらのコミュニティの少なくとも1つがあります。
Each of the following occurs at provisioning time: if a service provider adds a new L1VPN port to a particular PE, this port is associated with a PIT on that PE, and this PIT is associated with that L1VPN.
以下のそれぞれは、プロビジョニング時間に発生します。サービスプロバイダーが新しいL1VPNポートを特定のPEに追加する場合、このポートはそのPEのピットに関連付けられており、このピットはそのL1VPNに関連付けられています。
Note that since the protocol used to populate a PIT with remote information is BGP, and since BGP works across multiple autonomous systems (ASs), it follows that the mechanism described in this document could support L1VPNs that span multiple autonomous systems.
PITにリモート情報を入力するために使用されるプロトコルはBGPであり、BGPが複数の自律システム（ASS）にわたって機能するため、このドキュメントで説明されているメカニズムが複数の自律システムにまたがるL1VPNをサポートできることに注意してください。
Although multi-AS L1VPNs are currently out of scope for the Basic Mode, the mechanisms defined in this document appear to be easily applicable to a multi-AS scenario, should such a need arise in the future. At that time, additional work may be required to examine various aspects including security.
Multi-AS L1VPNは現在、基本モードの範囲外ですが、このドキュメントで定義されているメカニズムは、そのような必要性が将来発生した場合、Multi-ASシナリオに簡単に適用できるようです。当時、セキュリティを含むさまざまな側面を調べるには、追加の作業が必要になる場合があります。
The <CPI, PPI> mapping is carried using the Multiprotocol Extensions to BGP [RFC4760]. [RFC4760] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, that can be used to announce and withdraw the announcement of reachability information. We introduce a new subsequent address family identifier, called Layer-1 VPN auto-discovery information (value 69), and also a new Network Layer Reachability Information (NLRI) format for carrying the CPI and PPI information.
<CPI、PPI>マッピングは、MultiProtocol拡張機能をBGP [RFC4760]に使用して運ばれます。[RFC4760]は、2つのBGP属性、MP_REACH_NLRIとMP_UNREACH_NLRIの形式を定義します。レイヤー-1 VPN自動配置情報（値69）と呼ばれる新しいアドレスファミリ識別子と、CPIおよびPPI情報を運ぶための新しいネットワークレイヤーリーチ可能性情報（NLRI）形式を紹介します。
One or more <PPI, CPI> tuples could be carried in the above mentioned BGP attributes.
1つ以上の<PPI、CPI>タプルは、上記のBGP属性に携帯することができます。
The format of the NLRI is described in Figure 2.
NLRIの形式を図2に示します。
+---------------------------------------+
| Length (1 octet) |
|長さ（1オクテット）|
+---------------------------------------+
| Auto-discovery info (variable) |
|自動発見情報（変数）|
+---------------------------------------+
Figure 2: Encoding of the NLRI
図2：NLRIのエンコーディング
Note that the encoding of the auto-discovery information is described in [L1VPN-BM], and note also that if the value of the Length of the Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address.
自動発見情報のエンコードは[L1VPN-BM]で説明されていることに注意してください。また、次のホップフィールドの長さ（MP_REACH_NLRI属性の）の値の値が4である場合、次のホップにはIPv4が含まれていることに注意してください。住所。この値が16の場合、次のホップにはIPv6アドレスが含まれています。
In addition to reachability information, the auto-discovery mechanism MAY carry Traffic Engineering information used for the purpose of egress path selection. For example, a PE may learn the switching capability and the maximum LSP bandwidth of remote L1VPN interfaces from the remote PEs. This document uses the BGP Traffic Engineering Attribute [BGP-TE-ATTRIBUTE] to carry such information.
到達可能性情報に加えて、自動発見メカニズムは、出力パス選択を目的として使用されるトラフィックエンジニアリング情報を運ぶ場合があります。たとえば、PEは、リモートPESからのリモートL1VPNインターフェイスのスイッチング機能と最大LSP帯域幅を学習する場合があります。このドキュメントでは、BGPトラフィックエンジニアリング属性[BGP-TE-ATTRIBUTE]を使用して、そのような情報を伝えます。
Recall that the Service Provider network consists of (a) PEs, (b) BGP Route Reflectors, (c) P nodes (which are neither PEs nor Route Reflectors), and, in the case of multi-provider VPNs, (d) Autonomous System Border Routers (ASBRs).
サービスプロバイダーネットワークは、（a）PES、（b）BGPルートリフレクター、（c）Pノード（PESもルートリフレクターもルートでもない）、およびマルチプロバイダーVPNSの場合、（d）自律的で構成されていることを思い出してください。システムボーダールーター（ASBRS）。
A PE router, unless it is a Route Reflector, does not retain L1VPN-related information unless it has at least one VPN with an import Route Target identical to one of the VPN-related information Route Target attributes. If a PE does not have a VPN with a matching import Route Target, it MUST then discard received l1VPN information. Inbound filtering MUST be used to cause such information to be discarded. If a new import Route Target is later added to one of the PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN-related information it previously has discarded.
PEルーターは、ルートリフレクターでない限り、VPN関連の情報ルートターゲット属性のいずれかと同一のインポートルートターゲットを持つ少なくとも1つのVPNを持つ場合を除き、L1VPN関連情報を保持しません。PEが一致するインポートルートターゲットを備えたVPNを持っていない場合、受信したL1VPN情報を破棄する必要があります。インバウンドフィルタリングを使用して、そのような情報を破棄する必要があります。後で新しいインポートルートターゲットがPEのVPNの1つ（「VPN Joan」操作）に追加された場合、以前に破棄したVPN関連情報を取得する必要があります。
In this case, the refresh mechanism described in [BGP-RFSH] MUST be used. The outbound route filtering mechanisms of [BGP-ORF] and [BGP-CONS] can also be used to advantage to make the filtering more dynamic.
この場合、[BGP-RFSH]で説明されている更新メカニズムを使用する必要があります。[BGP-ORF]および[BGP-CON]のアウトバウンドルートフィルタリングメカニズムを使用して、フィルタリングをより動的にするために有利にすることもできます。
Similarly, if a particular import Route Target is no longer present in any of a PE's VPN (as a result of one or more "VPN Prune" operations), the PE MAY discard all the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes.
同様に、特定の輸入ルートターゲットがPEのVPNのいずれにも存在しなくなった場合（1つ以上の「VPN Prune」操作の結果として）、PEはすべてのL1VPN BGPルートを破棄する可能性があります。PEのピットの輸入ルートターゲットを、ルートターゲット属性の1つとしてターゲットにします。
Note that "VPN Join" and "VPN Prune" operations are non-disruptive, and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used.
[BGP-RFSH]の更新メカニズムが使用されている限り、「VPN結合」および「VPN Prune」操作は破壊的であり、BGP接続を倒す必要はないことに注意してください。
As a result of these distribution rules, no one PE ever needs to maintain all routes for all L1VPNs; this is an important scalability consideration.
これらの配布規則の結果として、すべてのL1VPNのすべてのルートを維持する必要はありません。これは重要なスケーラビリティの考慮事項です。
Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the L1VPNs supported by the Service Provider. Thus, no single route reflector is required to maintain VPN-related information for all VPNs.
ルートリフレクターをVPN間でパーティション化できるため、各パーティションは、サービスプロバイダーがサポートするL1VPNのサブセットのみのルートを運ぶことができます。したがって、すべてのVPNのVPN関連情報を維持するために、単一のルートリフレクターは必要ありません。
For inter-provider VPNs, if multi-hop External BGP (EBGP) is used, then the ASBRs need not maintain and distribute VPN-related information at all. P routers do not maintain any VPN-related information.
プロバイダー間VPNの場合、マルチホップ外部BGP（EBGP）を使用する場合、ASBRはVPN関連情報をまったく維持および配布する必要はありません。Pルーターは、VPN関連情報を維持していません。
As a result, no single component within the Service Provider network has to maintain all the VPN-related information for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
その結果、サービスプロバイダーネットワーク内の単一のコンポーネントは、すべてのVPNのすべてのVPN関連情報を維持する必要はありません。したがって、VPNの数の増加をサポートするネットワークの総容量は、個々のコンポーネントの容量によって制限されません。
An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the case of the Internet, where the Internet BGP system MUST carry all the Internet routes. Thus, one significant (but perhaps subtle) distinction between the use of BGP for the Internet routing and the use of BGP for distributing VPN-related information, as described in this document, is that the former is not amenable to partition, while the latter is.
覚えておくべき重要な考慮事項は、VPN関連の情報を運ぶ独立したBGPシステムが何度もある可能性があることです。これは、インターネットBGPシステムがすべてのインターネットルートを運ぶ必要があるインターネットの場合とは異なります。したがって、このドキュメントで説明されているように、インターネットルーティングにBGPを使用することとVPN関連情報を配布するためのBGPの使用との間の1つの重要な（しかし、おそらく微妙な）区別は、前者はパーティションを受けることができず、後者はは。
This document describes a BGP-based auto-discovery mechanism that enables a PE that attaches to a particular L1VPN to discover the set of other PE routers that attach to the same VPN. Each PE router that is attached to a given VPN uses BGP to advertise that fact. Other PE routers that attach to the same VPN receive these BGP advertisements. This allows that set of PEs to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements can be received from "intermediate" BGP speakers.
このドキュメントでは、特定のL1VPNに取り付けられたPEが同じVPNに付着する他のPEルーターのセットを発見できるBGPベースの自動発見メカニズムについて説明します。特定のVPNに接続されている各PEルーターは、BGPを使用してその事実を宣伝します。同じVPNに接続する他のPEルーターは、これらのBGP広告を受け取ります。これにより、その一連のPEがお互いを発見することができます。PEは、常にリモートPEからこれらの広告を直接受信するとは限らないことに注意してください。広告は、「中間」BGPスピーカーから受け取ることができます。
It is of critical importance that a particular PE MUST NOT be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE nodes, and if the PE nodes accepted those advertisements, then anyone could add any site to any L1VPN. Thus, the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further, that it can trust those peers to be properly securing their local attachments. (That is, a PE MUST trust that its peers are attached to, and are authorized to be attached to, the L1VPNs to which they claim to be attached.)
特定のPEを特定のVPNに「発見」してはならないことが非常に重要であり、そのPEが実際にそのVPNに添付されていない限り、実際にそのVPNに添付されることを適切に許可されています。インターネット上の任意のノードがこれらのBGP広告の送信を開始し、それらの広告がPEノードに到達できる場合、およびPEノードがそれらの広告を受け入れた場合、誰でも任意のL1VPNにサイトを追加できます。したがって、ここで説明した自動発見手順は、特定のPEがBGPのピアが彼らが誰であるかを信頼していることを前提としており、さらに、それらのピアが地元の添付ファイルを適切に保護することを信頼できることを推定しています。（つまり、PEは、その仲間が添付されているL1VPNに添付されていることを信頼しなければなりません。
If a particular remote PE is a BGP peer of the local PE, then the BGP authentication procedures of [RFC2385] SHOULD be used to ensure that the remote PE is who it claims to be, i.e., that it is a PE that is trusted.
特定のリモートPEがローカルPEのBGPピアである場合、[RFC2385]のBGP認証手順を使用して、リモートPEがそれが誰であるか、つまり信頼できるPEであることを確認する必要があります。
If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE MUST trust that its peers only accept information from peers that they trust in turn, and this trust relation MUST be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence, the procedures of this document MUST be used only in environments where adequate trust relationships exist among the BGP speakers (such as the case of using the auto-discovery mechanism within a single provider network).
特定のリモートPEがローカルPEのBGPピアではない場合、広告である情報は、BGPスピーカーのチェーンを介してローカルPEに配布されています。地元のPEは、仲間が順番に信頼できる仲間からの情報のみを受け入れることを信頼する必要があり、この信頼関係は推移的でなければなりません。BGPは、その特定の情報を宣伝することが許可されたBGPスピーカーに由来する特定の受け取った情報を決定する方法を提供しません。したがって、このドキュメントの手順は、BGPスピーカーの間に適切な信頼関係が存在する環境でのみ使用する必要があります（単一のプロバイダーネットワーク内で自動配置メカニズムを使用する場合など）。
This document assigns a new SAFI, called Layer-1 VPN auto-discovery information (see Section 3). This assignment has been made in the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. The value is 69.
このドキュメントには、レイヤー1 VPNオートディスコーブリ情報と呼ばれる新しいSAFIが割り当てられます（セクション3を参照）。この割り当ては、標準のアクション割り当て手順を使用して、後続のアドレスファミリー識別子（SAFI）レジストリで行われました。値は69です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RFSH] Chen、E。、「BGP-4のルートリフレッシュ機能」、RFC 2918、2000年9月。
[BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-Te-Attribute] Oould-Brahim、H.、Fedyk、D。、およびRekhter、Y。、「Traffic Engineering属性」、2008年1月の作業。
[BGP-ORF] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", Work in Progress, September 2006.
[BGP-ORF] Chen、E。およびY. Rekhter、「BGP-4のアウトバウンドルートフィルタリング機能」、2006年9月、進行中の作業。
[BGP-CONS] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[BGP-Cons] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、 "境界ゲートウェイプロトコル/マルチプロトコルの制約されたルート分布ラベルスイッチング（BGP/MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS） "、RFC 4684、2006年11月。
[BGP-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-COMM] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[L1VPN-FRMK] Takeda、T.、ed。、「レイヤー1仮想プライベートネットワークのフレームワークと要件」、RFC 4847、2007年4月。
[L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Work in Progress, February 2008.
[L1VPN-BM] Fedyk、D.、ed。、Rekhter、Y.、ed。、Papadimitriou、D.、Rabbat、R.、およびL. Berger、「レイヤー1 VPN基本モード」、進行中の作業、2008年2月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
We would like to thank Adrian Farrel for the useful comments.
有用なコメントについては、エイドリアンファレルに感謝します。
Authors' Addresses
著者のアドレス
Hamid Ould-Brahim Nortel PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada
ハミド・ロールド・ブラヒム・ノルテル・ポックス3511ステーションCオタワK1Y 4H7カナダ
Phone: +1 (613) 763 4730
EMail: hbrahim@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: yakov@juniper.net
Don Fedyk Nortel 600 Technology Park Billerica, MA 01821 USA
Don Fedyk Nortel 600テクノロジーパークビレリカ、マサチューセッツ州01821 USA
Phone: +1 (978) 288 3041
Email: dwfedyk@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。