RFC1773 日本語訳
1773 Experience with the BGP-4 protocol. P. Traina. March 1995. (Format: TXT=19936 bytes) (Obsoletes RFC1656) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Traina Request for Comments: 1773 cisco Systems Obsoletes: 1656 March 1995 Category: Informational
Trainaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1773年のコクチマスSystems Obsoletes: 1656 1995年3月のカテゴリ: 情報
Experience with the BGP-4 protocol
BGP-4プロトコルの経験
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Introduction
序論
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This is the second of two reports on the BGP protocol. As required by the Internet Architecure Board (IAB) and the Internet Engineering Steering Group (IESG), the first report will present a performance analysis of the BGP protocol.
このメモの目的はボーダ・ゲイトウェイ・プロトコルバージョン4(BGP-4)によってルーティング・プロトコルをDraft Standardに唱えるための要件がどう満たされたかを記録することです。 このレポートはBGPの経験を記録します。 これはBGPプロトコルに関する2つのレポートの2番目です。 必要に応じて、BGPプロトコルの機能解析を提示するでしょうEngineering Steering Group(IESG)、インターネットArchitecure Board(IAB)とインターネットのそばの1番目が、報告する。
The remaining sections of this memo document how BGP satisfies General Requirements specified in Section 3.0, as well as Requirements for Draft Standard specified in Section 5.0 of the "Internet Routing Protocol Standardization Criteria" document [1].
このメモの残っているセクションは「インターネットルーティング・プロトコル標準化評価基準」というドキュメント[1]のセクション5.0で指定されたDraft StandardのためにBGPがどうセクション3.0で指定されたRequirements司令官、およびRequirementsを満たすかを記録します。
This report is based on the initial work of Peter Lothberg (Ebone), Andrew Partan (Alternet), and several others. Details of their work were presented at the Twenty-fifth IETF meeting and are available from the IETF proceedings.
このレポートはピーターLothberg(Ebone)、アンドリューPartan(Alternet)、および数人の他のものの初期の仕事に基づいています。 彼らの仕事の詳細は、Twenty-第5IETFミーティングに提示されて、IETF議事によって利用可能です。
Please send comments to iwg@ans.net.
コメントを iwg@ans.net に送ってください。
Acknowledgments
承認
The BGP protocol has been developed by the IDR (formerly BGP) Working Group of the Internet Engineering Task Force. I would like to express deepest thanks to Yakov Rekhter and Sue Hares, co-chairs of the IDR working group. I'd also like to explicitly thank Yakov Rekhter and Tony Li for the review of this document as well as constructive and valuable comments.
BGPプロトコルはインターネット・エンジニアリング・タスク・フォースのIDR(以前BGP)作業部会によって開発されました。 IDRワーキンググループのヤコフRekhterとスーHares、共同議長に最も深い感謝を申し上げたいと思います。 また、建設的で貴重なコメントと同様にこのドキュメントのレビューについて明らかにヤコフRekhterとトニー・李に感謝申し上げます。
Traina [Page 1] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[1ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
Documentation
ドキュメンテーション
BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. Version 1 of the BGP protocol was published in RFC 1105. Since then BGP Versions 2, 3, and 4 have been developed. Version 2 was documented in RFC 1163. Version 3 is documented in RFC 1267. The changes between versions 1, 2 and 3 are explained in Appendix 2 of [2]. All of the functionality that was present in the previous versions is present in version 4.
BGPはTCP/IPインターネットのために設計された相互自律システムルーティング・プロトコルです。 BGPプロトコルのバージョン1はRFC1105で発行されました。 それ以来、BGPバージョン2、3、および4を開発してあります。 バージョン2はRFC1163に記録されました。 バージョン3はRFC1267に記録されます。 バージョン1、2、および3の間の変化は[2]のAppendix2で説明されます。 旧バージョンに存在している機能性のすべてがバージョン4に出席しています。
BGP version 2 removed from the protocol the concept of "up", "down", and "horizontal" relations between autonomous systems that were present in version 1. BGP version 2 introduced the concept of path attributes. In addition, BGP version 2 clarified parts of the protocol that were "under-specified".
BGPバージョン2はプロトコルから“up"、“down"、およびバージョン1に存在している自律システムの「水平な」関係の概念を取り除きました。 BGPバージョン2は経路属性の概念を紹介しました。 さらに、BGPバージョン2は「下の指定された」プロトコルの部分をはっきりさせました。
BGP version 3 lifted some of the restrictions on the use of the NEXT_HOP path attribute, and added the BGP Identifier field to the BGP OPEN message. It also clarifies the procedure for distributing BGP routes between the BGP speakers within an autonomous system.
BGPバージョン3は、ネクスト_HOP経路属性の使用のときに制限のいくつかについて提案して、BGP Identifier分野をBGP OPENメッセージに追加しました。 また、それは自律システムの中のBGPスピーカーの間のBGPルートを分配するための手順をはっきりさせます。
BGP version 4 redefines the (previously class-based) network layer reachability portion of the updates to specify prefixes of arbitrary length in order to represent multiple classful networks in a single entry as discussed in [5]. BGP version 4 has also modified the AS- PATH attribute so that sets of autonomous systems, as well as individual ASs may be described. In addition, BGP version for has redescribed the INTER-AS METRIC attribute as the MULTI-EXIT DISCRIMINATOR and added new LOCAL-PREFERENCE and AGGREGATOR attributes.
BGPバージョン4は、[5]で議論するように単一のエントリーにおける複数のclassfulネットワークを代表するために任意の長さの接頭語を指定するためにアップデートの(以前にクラスベース)のネットワーク層可到達性部分を再定義します。 また、BGPバージョン4がAS- PATH属性を変更したので、それは自律システムをセットします、個々のASsとしての井戸が説明されるとき。 追加、BGPバージョン、MULTI-EXIT DISCRIMINATORとしてINTER-AS METRIC属性について再説明して、新しいLOCAL-PREFERENCEとAGGREGATOR属性を加えました。
Possible applications of BGP in the Internet are documented in [3].
インターネットのBGPの可能なアプリケーションは[3]に記録されます。
The BGP protocol was developed by the IDR Working Group of the Internet Engineering Task Force. This Working Group has a mailing list, iwg@ans.net, where discussions of protocol features and operation are held. The IDR Working Group meets regularly during the quarterly Internet Engineering Task Force conferences. Reports of these meetings are published in the IETF's Proceedings.
BGPプロトコルはインターネット・エンジニアリング・タスク・フォースのIDR作業部会によって開発されました。 この作業部会にはメーリングリスト、 iwg@ans.net があります。そこでは、プロトコル機能と操作の議論が行われます。 IDR作業部会は四半期のインターネット・エンジニアリング・タスク・フォース会議の間、定期的に会合します。 これらのミーティングのレポートはIETFのProceedingsで発表されます。
MIB
MIB
A BGP-4 Management Information Base has been published [4]. The MIB was written by Steve Willis (Wellfleet), John Burruss (Wellfleet), and John Chu (IBM).
BGP-4 Management Information基地は発行されました。[4]。 MIBはスティーブ・ウィリス(Wellfleet)、ジョンBurruss(Wellfleet)、およびジョン・チュウ(IBM)によって書かれました。
Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table.
いくつかのシステム変数は別として、2個のテーブルがBGP MIBに細かく分けられます: BGP同輩テーブルとBGPは経路属性テーブルを受けました。
Traina [Page 2] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[2ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table.
Peer Tableは彼らの状態や現在の活動などのBGP同輩接続の情報を反映します。 Received Path Attribute Tableはローカルのルーティング方針が適用される前にすべての同輩から受け取られたすべての属性を含んでいます。 ルートを決定する際に使用される実際の属性は容認された属性テーブルの部分集合です。
Security Considerations
セキュリティ問題
BGP provides flexible and extendible mechanism for authentication and security. The mechanism allows to support schemes with various degree of complexity. All BGP sessions are authenticated based on the BGP Identifier of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer. As part of the BGP authentication mechanism, the protocol allows to carry encrypted digital signature in every BGP message. All authentication failures result in sending the NOTIFICATION messages and immediate termination of the BGP connection.
BGPはフレキシブルで拡張可能なメカニズムを認証とセキュリティに提供します。 メカニズムは様々な度合いの複雑さがある体系をサポートに許容します。 すべてのBGPセッションが同輩のBGP Identifierに基づいて認証されます。 さらに、すべてのBGPセッションが同輩によって広告に掲載された自律システム番号に基づいて認証されます。 BGP認証機構の一部として、プロトコルで、あらゆるBGPメッセージにおける暗号化されたデジタル署名を運びます。 すべての認証失敗がBGP接続のNOTIFICATIONメッセージを送って、即座の終了をもたらします。
Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP.
BGPがTCPとIPをひくので、BGPの認証体系はTCPかIPのどちらかによって提供されたどんな認証やセキュリティー対策によっても増大させられるかもしれません。
However, since BGP runs over TCP and IP, BGP is vulnerable to the same denial of service or authentication attacks that are present in any other TCP based protocol.
しかしながら、BGPがTCPとIPをひくので、BGPはいかなる他のTCPのベースのプロトコルでも存在しているサービスか認証攻撃の同じ否定に被害を受け易いです。
Implementations
実装
There are multiple independent interoperable implementations of BGP currently available. This section gives a brief overview of the implementations that are currently used in the operational Internet. They are:
BGPの現在利用可能な複数の独立している共同利用できる実装があります。 このセクションは現在操作上のインターネットで使用される実装の簡潔な概要を与えます。 それらは以下の通りです。
- cisco Systems - gated consortium - 3COM - Bay Networks (Wellfleet) - Proteon
- コクチマスSystems--外出を禁止された共同体--3COM--ベイネットワークス(Wellfleet)--Proteon
To facilitate efficient BGP implementations, and avoid commonly made mistakes, the implementation experience with BGP-4 in with cisco's implementation was documented as part of RFC 1656 [4].
効率的なBGP実装を容易にして、一般的に人工の誤りを避けるために、コクチマスの実装がある中のBGP-4の実装経験はRFC1656[4]の一部として記録されました。
Implementors are strongly encouraged to follow the implementation suggestions outlined in that document and in the appendix of [2].
作成者がそのドキュメントと[2]の付録に概説された実装提案に続くよう強く奨励されます。
Traina [Page 3] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[3ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
Experience with implementing BGP-4 showed that the protocol is relatively simple to implement. On the average BGP-4 implementation takes about 2 man/months effort, not including any restructuring that may be needed to support CIDR.
BGP-4を実装する経験は、プロトコルは実装するのが比較的簡単であることを示しました。 平均して、BGP-4実装はおよそ2男性/カ月の取り組みを取ります、CIDRをサポートするのに必要であるどんな企業再構築も含んでいなくて。
Note that, as required by the IAB/IESG for Draft Standard status, there are multiple interoperable completely independent implementations.
Draft Standard状態のために必要に応じてIAB/IESGでそれに注意してください、そして、複数の共同利用できる完全に独立している実装があります。
Operational experience
運用経験
This section discusses operational experience with BGP and BGP-4.
このセクションはBGPとBGP-4の運用経験について論じます。
BGP has been used in the production environment since 1989, BGP-4 since 1993. This use involves at least two of the implementations listed above. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of the link bandwidth it varies from 28 Kbits/sec to 150 Mbits/sec. In terms of the actual routes that run BGP it ranges from a relatively slow performance PC/RT to a very high performance RISC based CPUs, and includes both the special purpose routers and the general purpose workstations running UNIX.
1989、1993年以来のBGP-4以来BGPは実稼動環境に使用されています。 この使用は少なくとも上に記載された2つの実装を伴います。 BGPの生産使用はプロトコルに関するすべての著しい特徴の利用を含んでいます。 現在の実稼動環境はBGPが相互自律システムルーティング・プロトコルとして使用されるところで非常に異種です。 28キロビット/秒から150メガビット/秒に変えるリンク帯域幅に関して BGPを実行する実際のルートで、それは、比較的遅い性能PC/RTから非常に高いベースの性能RISC CPUまで及んで、専用ルータとUNIXを実行する汎用のワークステーションの両方を含んでいます。
In terms of the actual topologies it varies from a very sparse (spanning tree of ICM) to a quite dense (NSFNET backbone).
実際のtopologiesに関して、それは非常にまばらな(ICMのスパニングツリー)aから全く濃い状態で(NSFNETバックボーン)異なります。
At the time of this writing BGP-4 is used as an inter-autonomous system routing protocol between ALL significant autonomous systems, including, but by all means not limited to: Alternet, ANS, Ebone, ICM, IIJ, MCI, NSFNET, and Sprint. The smallest know backbone consists of one router, whereas the largest contains nearly 90 BGP speakers. All together, there are several hundred known BGP speaking routers.
この書くこと時点で、BGP-4はすべての重要な自律システムの間の相互自律システムルーティング・プロトコル、包含として使用されますが、必ず、以下のことのために制限されません。 Alternet、ANS、Ebone、ICM、IIJ、MCI、NSFNET、およびスプリント。 最も小さいのは、バックボーンが1つのルータから成るのを知っていますが、最も大きいのはおよそ90人のBGPスピーカーを含みます。 一斉に、ルータを話す数100の知られているBGPがあります。
BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no distinction between sites historically considered backbones vs "regional" networks.
BGPはトランジットとスタッブ自律システムの間のルーティング情報の交換、および複数のトランジット自律システムの間のルーティング情報の交換に使用されます。区別は全くバックボーンであると歴史的に考えられたサイトの間に「地方」のネットワークに反対していません。
Within most transit networks, BGP is used as the exclusive carrier of the exterior routing information. At the time of this writing within a few sites use BGP in conjunction with an interior routing protocol to carry exterior routing information.
ほとんどの輸送網の中では、BGPは外のルーティング情報の排他的なキャリヤーとして使用されます。 いくつかのサイトの中のこの書くこと時点で、内部のルーティング・プロトコルに関連してBGPを使用して、外のルーティング情報を運んでください。
Traina [Page 4] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[4ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
The full set of exterior routes that is carried by BGP is well over 20,000 aggregate entries representing several times that number of connected networks.
2万の集合エントリーのかなり上にBGPによって運ばれる外のルートのフルセットが、接続ネットワークのその数について何度かを表しながら、あります。
Operational experience described above involved multi-vendor deployment (cisco, and "gated").
上で説明された運用経験はマルチベンダ展開(コクチマスの、そして、「外出を禁止された」)にかかわりました。
Specific details of the operational experience with BGP in Alternet, ICM and Ebone were presented at the Twenty-fifth IETF meeting (Toronto, Canada) by Peter Lothberg (Ebone), Andrew Partan (Alternet) and Paul Traina (cisco).
Alternet、ICM、およびEboneのBGPの運用経験の特定の詳細はTwenty-第5IETFミーティング(トロント(カナダ))にピーターLothberg(Ebone)、アンドリューPartan(Alternet)、およびポールTraina(コクチマス)によって提示されました。
Operational experience with BGP exercised all basic features of the protocol, including authentication, routing loop suppression and the new features of BGP-4, enhanced metrics and route aggregation.
BGPの運用経験はプロトコルに関するすべての基本的特徴を運動させました、BGP-4、高められた測定基準、およびルート集合に関する認証、ルーティング輪の抑圧、および新機能を含んでいて。
Bandwidth consumed by BGP has been measured at the interconnection points between CA*Net and T1 NSFNET Backbone. The results of these measurements were presented by Dennis Ferguson during the Twenty- first IETF, and are available from the IETF Proceedings. These results showed clear superiority of BGP as compared with EGP in the area of bandwidth consumed by the protocol. Observations on the CA*Net by Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares confirmed clear superiority of the BGP protocol family as compared with EGP in the area of CPU requirements.
BGPによって消費された帯域幅はカリフォルニア*のネットとT1 NSFNET Backboneの間のインタコネクトポイントで測定されました。 これらの測定値の結果は、Twenty最初のIETFの間、デニスファーガソンによって提示されて、IETF Proceedingsから利用可能です。 これらの結果はプロトコルによって消費された帯域幅の領域のEGPと比べてBGPの明確な優越を示しました。 カリフォルニア*における観測はCPU要件の領域のEGPと比べてBGPプロトコルファミリーを優越から取り除きますデニスファーガソンの近くと、そして、スーザンHaresによるT1 NSFNET Backboneの上のネットが、確認した。
Migration to BGP version 4
BGPバージョン4への移行
On multiple occasions some members of IETF expressed concern about the migration path from classful protocols to classless protocols such as BGP-4.
複数の時に、IETFの何人かのメンバーがBGP-4などのclassfulプロトコルから階級のないプロトコルまでの移行パスに関して懸念を示しました。
BGP-4 was rushed into production use on the Internet because of the exponential growth of routing tables and the increase of memory and CPU utilization required by BGP. As such, migration issues that normally would have stalled deployment were cast aside in favor of pragmatic and intelligent deployment of BGP-4 by network operators.
BGP-4は経路指定テーブルの急激な増加とメモリの増加のためにインターネットを生産使用に急いで運ばれました、そして、CPU使用率がBGPが必要です。 そういうものとして傍らにキャストがネットワーク・オペレータによるBGP-4の実践的で知的な展開を支持してあったなら通常、展開を遅らせた移行問題。
There was much discussion about creating "route exploders" which would enumerate individual class-based networks of CIDR allocations to BGP-3 speaking routers, however a cursory examination showed that this would vastly hasten the requirement for more CPU and memory resources for these older implementations. There would be no way internal to BGP to differentiate between known used networks and the unused portions of the CIDR allocation.
CIDR配分の個々のクラスを拠点とするネットワークをBGP-3に数え上げる「ルート発破器」を作成するのとルータを話す多くの議論があって、しかしながら、粗略な試験は、これが広大により多くのCPUのための要件とこれらのより古い実装のためのメモリリソースを急がせるのを示しました。 CIDR配分の知られている中古のネットワークと未使用の部分を区別するBGPへの内部のどんな道もないでしょう。
The migration path chosen by the majority of the operators was known as "CIDR, default, or die!"
オペレータの大部分によって選ばれた移行パスは「CIDR、デフォルトとするか、または死んでください!」として知られていました。
Traina [Page 5] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[5ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
To test BGP-4 operation, a virtual "shadow" Internet was created by linking Alternet, Ebone, ICM, and cisco over GRE based tunnels. Experimentation was done with actual live routing information by establishing BGP version 3 connections with the production networks at those sites. This allowed extensive regression testing before deploying BGP-4 on production equipment.
BGP-4操作をテストするために、仮想の「影」インターネットはGREのベースのトンネルの上のAlternet、Ebone、ICM、およびコクチマスをリンクすることによって、作成されました。 実験は実際でそれらのサイトの生産ネットワークとのBGPバージョン3接続を確立することによって情報を発送しライブな状態で終わっていました。 生産設備の上のBGP-4を配布する前に、これは大規模な回帰試験を許容しました。
After testing on the shadow network, BGP-4 implementations were deployed on the production equipment at those sites. BGP-4 capable routers negotiated BGP-4 connections and interoperated with other sites by speaking BGP-3. Several test aggregate routes were injected into this network in addition to class-based networks for compatibility with BGP-3 speakers.
影のネットワークでテストした後に、BGP-4実装はそれらのサイトの生産設備の上で配布されました。 BGP-4のできるルータは、BGP-3を話すことによって、BGP-4接続を交渉して、他のサイトで共同利用しました。 数個がBGP-3スピーカーとの互換性のためのクラスを拠点とするネットワークに加えてこのネットワークに注がれた状態で集合ルートをテストします。
At this point, the shadow-Internet was re-chartered as an "operational experience" network. tunnel connections were established with most major transit service operators so that operators could gain some understanding of how the introduction of aggregate networks would affect routing.
ここに、影インターネットは「運用経験」ネットワークとして再チャーターされました。トンネル接続は、オペレータが集合ネットワークの導入がどうルーティングに影響するだろうかに関する何らかの理解を獲得できるように、ほとんどの一流のトランジットサービスオペレータと共に確立されました。
After being satisfied with the initial deployment of BGP-4, a number of sites chose to withdraw their class-based advertisements and rely only on their CIDR aggregate advertisements. This provided motivation for transit providers who had not migrated to either do so, accept a default route, or lose connectivity to several popular destinations.
BGP-4の初期の展開に満たされた後に、多くのサイトが、彼らのクラスベースの広告を引き下がらせて、彼らのCIDRの集合広告だけに依存するのを選びました。 提供されたそうしたトランジットプロバイダーに関するこの動機は、そうするか、デフォルトルートを受け入れるか、またはいくつかのポピュラーな目的地に接続性を失うために移行しませんでした。
Metrics
測定基準
BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT- DISCRIMINATOR. This value may be used in the tie breaking process when selecting a preferred path to a given address space. The MED is meant to only be used when comparing paths received from different external peers in the same AS to indicate the preference of the originating AS.
BGPバージョン4はMULTI-EXIT- DISCRIMINATORとしてのメートル法の古いINTER-ASを再定義しました。 この値は都合のよい経路を与えられたアドレス空間に選択するときプロセスを壊す繋がりに使用されるかもしれません。 起因しているASの好みを示すために同じASで異なった外部の同輩から受け取られた経路を比較するときだけ、MEDは使用されることになっています。
The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was insure that peers could not "shed" or "absorb" traffic for networks that they advertise.
遅く最も良い経路決定プロセスで使用されるだけであるMEDは、a「弱い」メートル法であるためにわざわざ設計されました。 BGPワーキンググループは関係があった、それ、少しもメートル法、リモートオペレータによって指定されて、他の好みが全く指定されない場合にだけ、地方のASでのルーティングに影響するでしょうに。 MEDのデザインの最高の目標は同輩がそれらが広告を出すネットワークのためにトラフィックを「落ちる」か、または「吸収できなかったこと」を保障することでした。
The LOCAL-PREFERENCE attribute was added so a local operator could easily configure a policy that overrode the standard best path determination mechanism without configuring local preference on each router.
ローカルのオペレータが容易に各ルータにおける地方の好みを構成しないで標準の最も良い経路決断メカニズムをくつがえした方針を構成できるように、LOCAL-PREFERENCE属性は加えられました。
Traina [Page 6] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[6ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
One shortcoming in the BGP4 specification was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided. Defaults of 0 or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL-PREF is a local administration knob, there is no interoperability drawback across AS boundaries).
なにも提供されなかったなら、BGP4仕様による1つの短所はLOCAL-PREFのデフォルト値が想定される提案でした。 それぞれ0のデフォルトか最大値には範囲制限があるので、一般的なデフォルトは同じASのマルチベンダルータのinteroperationで支援されるでしょう(LOCAL-PREFが地方行政ノブであるので、相互運用性欠点が全くAS境界のむこうにありません)。
Another area where more exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup.
より多くの探検が必要である別の領域は由来しているASが影響を及ぼすかもしれない中で経路選択の過程最も良い方法です。 例えば、二元的に接続されたサイトは、第一のトランジットサービスプロバイダーとして1つを選んで、バックアップとして1つを持っているかもしれません。
/---- transit B ----\ end-customer transit A---- \---- transit C ----/
/---- トランジットB----\末端顧客トランジットA---- \---- トランジットC----/
In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider and there is no mechanism for indicating a preference should the third provider wish to respect that preference.
2つのトランジットサービスプロバイダーが3番目のプロバイダーに接続するトポロジーでは、本当の決定が3番目のプロバイダーによって実行されます、そして、3番目のプロバイダーがその好みを尊敬したいと思うなら優先を示すためのメカニズムが全くありません。
A general purpose suggestion that has been brought up is the possibility of carrying an optional vector corresponding to the AS- PATH where each transit AS may indicate a preference value for a given route. Cooperating ASs may then chose traffic based upon comparison of "interesting" portions of this vector according to routing policy.
持って来られた汎用の提案は各トランジットASが好みの値を与えられたルートに示すかもしれないところまでAS- PATHに対応する任意のベクトルを運ぶ可能性です。 ASsがそしてときにそうするかもしれない協力はルーティング方針によると、このベクトルの「おもしろい」部分の比較に基づいた交通を選びました。
While protecting a given ASs routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols.
保護している間、与えられたASsルーティング方針は最高の関心のものです、将来のBGPのようなプロトコルで、より慎重に調べられるべきルーティング方針の必要性の大規模な手の構成を避けて。
Internal BGP in large autonomous systems
大きい自律システムの内部のBGP
While not strictly a protocol issue, one other concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS.
プロトコル問題、他の1回の関心が厳密でなくそうですが、ネットワーク・オペレータによって上げられて、だれが、多くがある自律システムを維持する必要があるかがじっと見ます。 外部のルータでじっと見ているそれぞれのスピーカーはそのASの中で他のすべてのトランジットと境界ルータに可到達性と経路情報を伝播するのに責任があります。 通常地方のASで内部のBGP接続をすべてのトランジットと境界ルータに確立することによって、これをします。
In a large AS, this leads to an n^2 mesh of TCP connections and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated, so alternatives, such as injecting BGP attribute information into the local IGP have been suggested. Also, there is effort underway to develop internal BGP "route reflectors" or a reliable multicast
大きいASでは、これはTCP接続のn^2メッシュとそれらの接続を構成して、維持する何らかの方法に通じます。 BGPが伝播されるこの情報がことである方法を指定しないので、BGP属性情報を地方のIGPに注ぐことなどの代替手段は提案されました。 また、内部のBGP「ルート反射鏡」か信頼できるマルチキャストを開発するためには進行中の努力があります。
Traina [Page 7] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[7ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
transport of IBGP information which would reduce configuration, memory and CPU requirements of conveying information to all other internal BGP peers.
他のすべての内部のBGPに情報を伝達する構成を減少させるIBGP情報の輸送、メモリ、およびCPU要件はじっと見ます。
Internet Dynamics
インターネット力学
As discussed in [7], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the net has grown, the number of changes per second has increased. We automatically get some level of damping when more specific NLRI is aggregated into larger blocks, however this isn't sufficient. In Appendix 6 of [2] are descriptions of dampening techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations.
[7]で議論するように、CPUと帯域幅利用における原動力はインターネットでのルーティングのダイナミックな本質です。 ネットが成長するのに従って、1秒あたりの変化の数は増加しました。 より特定のNLRIが、より大きいブロックに集められるとき、私たちは何らかのレベルについて自動的にじめじめとし始めて、しかしながら、これは十分ではありません。 [2]のAppendix6に、広告に適用されるべきである湿っているテクニックの記述があります。 BGPのようなプロトコルの将来の仕様では、湿気方法は対応する実現での義務的な包含のために考えられるべきです。
Acknowledgments
承認
The BGP-4 protocol has been developed by the IDR/BGP Working Group of the Internet Engineering Task Force. I would like to express thanks to Yakov Rekhter for providing RFC 1266. I'd also like to explicitly thank Yakov Rekhter and Tony Li for their review of this document as well as their constructive and valuable comments.
BGP-4プロトコルはインターネット・エンジニアリング・タスク・フォースのIDR/BGP作業部会によって開発されました。 ヤコフのおかげでRFC1266を提供するためにRekhterを急送したいと思います。 また、彼らの彼らの建設的で貴重なコメントと同様にこのドキュメントのレビューについて明らかにヤコフRekhterとトニー・李に感謝申し上げます。
Author's Address
作者のアドレス
Paul Traina cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
サンノゼ、ポールTrainaコクチマスSystems Inc.170W.タスマン博士カリフォルニア 95134
EMail: pst@cisco.com
メール: pst@cisco.com
References
参照
[1] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
[1]Hinden、R.、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、BBN、1991年10月。
[2] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.
[2]Rekhter、Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771、T.J.ワトソン研究所、IBM社、コクチマスSystems(1995年3月)。
[3] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.
[3] Rekhter、Y.と総計のP.エディターズ、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」RFC1772、T.J.ワトソン研究所、IBM社、MCI(1995年3月)。
Traina [Page 8] RFC 1773 Experience with the BGP-4 Protocol March 1995
Traina[8ページ]RFC1773は1995年3月にBGP-4と共にプロトコルを経験します。
[4] Willis, S., Burruss, J., and J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, Wellfleet Communications Inc., IBM Corp., July 1994.
[4] ウィリス、S.、Burruss、J.、およびJ.チュウ、「SMIv2"を使用して、境界ゲートウェイの第4バージョンのための管理オブジェクトの定義は(BGP-4)について議定書の中で述べます、RFC1657、WellfleetコミュニケーションInc.、IBM社、1994年7月」。
[5] Fuller V., Li. T., Yu J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993.
[5] フラーV.、李。 T.、ユーJ.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、MERIT、OARnet、9月1993日
[6] Traina P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, cisco Systems, July 1994.
[6] Traina P.、「BGP-4プロトコルは道路地図と実現経験を記録する」RFC1656、コクチマスSystems、1994年7月。
[7] Traina P., "BGP Version 4 Protocol Analysis", RFC 1774, cisco Systems, March 1995.
[7]Traina P.、「BGPバージョン4プロトコル分析」、RFC1774、コクチマスSystems、1995年3月。
Traina [Page 9]
Traina[9ページ]
一覧
スポンサーリンク