RFC1268 日本語訳

Network Working Group                                         Y. Rekhter
Request for Comments: 1268        T.J. Watson Research Center, IBM Corp.
Obsoletes: RFC 1164                                             P. Gross
                                                                     ANS
                                                                 Editors
                                                            October 1991

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1268 T.J.ワトソン研究所、IBM社は以下を時代遅れにします。 総計のP.ANSエディターズRFC1164 1991年10月

       Application of the Border Gateway Protocol in the Internet

インターネットでのボーダ・ゲイトウェイ・プロトコルの応用

Status of this Memo

このMemoの状態

   This protocol is being developed by the Border Gateway Protocol
   Working Group (BGP) of the Internet Engineering Task Force (IETF).
   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このプロトコルはインターネット・エンジニアリング・タスク・フォース(IETF)のボーダ・ゲイトウェイ・プロトコル作業部会(BGP)によって開発されています。 このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document, together with its companion document, "A Border
   Gateway Protocol (BGP-3)", define an inter-autonomous system routing
   protocol for the Internet.  "A Border Gateway Protocol (BGP-3)"
   defines the BGP protocol specification, and this document describes
   the usage of the BGP in the Internet.

仲間ドキュメントに伴う「ボーダ・ゲイトウェイ・プロトコル(BGP-3)」というこのドキュメントは相互自律システムルーティング・プロトコルをインターネットと定義します。 「ボーダ・ゲイトウェイ・プロトコル(BGP-3)」はBGPプロトコル仕様を定義します、そして、このドキュメントはインターネットでBGPの使用法を説明します。

   Information about the progress of BGP can be monitored and/or
   reported on the BGP mailing list (iwg@rice.edu).

BGPメーリングリスト( iwg@rice.edu )に関してBGPの進歩に関する情報をモニターされる、そして/または、報告できます。

Table of Contents

目次

   1. Introduction...................................................   2
   2. BGP Topological Model..........................................   3
   3. BGP in the Internet............................................   4
   4. Policy Making with BGP.........................................   5
   5. Path Selection with BGP........................................   6
   6. Required set of supported routing policies.....................   8
   7. Conclusion.....................................................   9
   Appendix A. The Interaction of BGP and an IGP.....................   9
   References........................................................  12
   Security Considerations...........................................  12
   Authors' Addresses................................................  13

1. 序論… 2 2. BGP位相モデル… 3 3. インターネットのBGP… 4 4. BGPとの方針作成… 5 5. BGPとの経路選択… 6 6. 支持されたルーティング方針をセットに要求します… 8 7. 結論… 9付録、A. BGPの相互作用とIGP… 9つの参照箇所… 12 セキュリティ問題… 12人の作者のアドレス… 13

Acknowledgements

承認

   This document was original published as RFC 1164 in June 1990,

このドキュメントは1990年6月にRFC1164として発行されていた状態でオリジナルでした。

BGP Working Group                                               [Page 1]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[1ページ]RFC1268アプリケーション

   jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
   (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
   (MERIT).

ジェフリー・C.ホニッグ(コーネル大学)、デーヴ・キャッツ(MERIT)、マット・マシス(PSC)、ヤコフRekhter(IBM)、およびジェシカ・ユー(MERIT)によって共同で書かれます。

   The following also made key contributions to RFC 1164 -- Guy Almes
   (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-
   Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).

また、以下が主要な貢献をした、RFC1164--奴のAlmes(そして、ライス大学のANS)、カーク・ロッキード(コクチマスSystems)、ハンスヴェルナーBraun(そして、MERITのSDSC)、およびスーHares(MERIT)。

   This updated version of the document is the product of the IETF BGP
   Working Group with Phillip Gross (ANS) and Yakov Rekhter (IBM) as
   editors.  John Moy (Proteon) contributed Section 6 "Recommended set
   of supported routing policies".

ドキュメントのこのアップデートされたバージョンはエディタとしてのフィリップGross(ANS)とヤコフRekhter(IBM)があるIETF BGP作業部会の製品です。 ジョンMoy(Proteon)は「お勧めのセットの支持されたルーティング方針」というセクション6を寄付しました。

   We also like to explicitly thank Bob Braden (ISI) for the review of
   this document as well as his constructive and valuable comments.

また、私たちは、彼の建設的で貴重なコメントと同様にこのドキュメントのレビューについて明らかにボブ・ブレーデン(ISI)に感謝するのが好きです。

1. Introduction

1. 序論

   This memo describes the use of the Border Gateway Protocol (BGP) [1]
   in the Internet environment. BGP is an inter-Autonomous System
   routing protocol. The network reachability information exchanged via
   BGP provides sufficient information to detect routing loops and
   enforce routing decisions based on performance preference and policy
   constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
   routing information containing full AS paths and enforces routing
   policies based on configuration information.

このメモはインターネット環境におけるボーダ・ゲイトウェイ・プロトコル(BGP)[1]の使用について説明します。 BGPは相互Autonomous Systemルーティング・プロトコルです。 BGPを通して交換されたネットワーク可到達性情報は、ルーティング輪を検出して、RFC1104[2]に概説されているように性能好みと方針規制に基づくルーティング決定を実施するために十分な情報を提供します。 BGPは特に、完全なAS経路を含むルーティング情報を交換して、設定情報に基づくルーティング方針を実施します。

   All of the discussions in this paper are based on the assumption that
   the Internet is a collection of arbitrarily connected Autonomous
   Systems. That is, the Internet will be modeled as a general graph
   whose nodes are AS's and whose edges are connections between pairs of
   AS's.

この紙における議論のすべてがインターネットが任意に接続されたAutonomous Systemsの収集であるという仮定に基づいています。すなわち、インターネットはノードがASのものであり、縁がASの組の間の接続である一般的なグラフとしてモデル化されるでしょう。

   The classic definition of an Autonomous System is a set of routers
   under a single technical administration, using an interior gateway
   protocol and common metrics to route packets within the AS, and using
   an exterior gateway protocol to route packets to other AS's. Since
   this classic definition was developed, it has become common for a
   single AS to use several interior gateway protocols and sometimes
   several sets of metrics within an AS. The use of the term Autonomous
   System here stresses the fact that, even when multiple IGPs and
   metrics are used, the administration of an AS appears to other AS's
   to have a single coherent interior routing plan and presents a
   consistent picture of which networks are reachable through it. From
   the standpoint of exterior routing, an AS can be viewed as
   monolithic: networks within an AS must maintain connectivity via
   intra-AS paths.

Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、ASの他のものにパケットを発送するのに外のゲートウェイプロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中でいくつかの内部のゲートウェイプロトコルと時々数セットの測定基準を使用するのは一般的になっています。 ここでのAutonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理がASの他のものにおいて現れるという事実を強調して、ネットワークがそれを通して届いている一貫した絵を提示します。 外のルーティングの見地から、一枚岩的であるとしてASを見なすことができます: ASの中のネットワークはイントラ-AS経路を通して接続性を維持しなければなりません。

BGP Working Group                                               [Page 2]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[2ページ]RFC1268アプリケーション

   AS's are assumed to be administered by a single administrative
   entity, at least for the purposes of representation of routing
   information to systems outside of the AS.

少なくともルーティング情報の表現の目的のためにASの外でただ一つの管理実体によってASのものによってシステムに管理されると思われます。

2. BGP Topological Model

2. BGP位相モデル

   When we say that a connection exists between two AS's, we mean two
   things:

ASのもの、接続が2の間に存在すると言うとき、私たちは2つのものを言っています:

      Physical connection:  There is a shared network between the two
      AS's, and on this shared network each AS has at least one border
      gateway belonging to that AS. Thus the border gateway of each AS
      can forward packets to the border gateway of the other AS without
      resort to Inter-AS or Intra-AS routing.

物理接続: ASの2ところの間には、共用回線網があります、そして、この共用回線網では、各ASは少なくとも1境界門にそのASに属させます。 したがって、それぞれのASの境界ゲートウェイはInter-ASへのリゾートもIntra-ASルーティングなしで他のASの境界ゲートウェイにパケットを送ることができます。

      BGP connection:  There is a BGP session between BGP speakers on
      each of the AS's, and this session communicates to each connected
      AS those routes through the physically connected border gateways
      of the other AS that can be used for specific networks. Throughout
      this document we place an additional restriction on the BGP
      speakers that form the BGP connection: they must themselves share
      the same network that their border gateways share. Thus, a BGP
      session between the adjacent AS's requires no support from either
      Inter-AS or Intra-AS routing. Cases that do not conform to this
      restriction fall outside the scope of this document.

BGP接続: それぞれのASのところのBGPスピーカーの間には、BGPセッションがあります、そして、このセッションは特定のネットワークに使用できる他のASの物理的に接続された境界ゲートウェイを通してそれぞれの接続ASにそれらのルートを伝えます。 このドキュメント中では、私たちはBGP接続を形成するBGPスピーカーに関して追加制限を課します: そうしなければならない、自分たち、それらの境界ゲートウェイが共有するのと同じネットワークを共有してください。 したがって、ASの隣接ところの間のBGPセッションはInter-ASかIntra-ASルーティングのどちらかからサポートを全く必要としません。 この制限に一致していないケースはこのドキュメントの範囲をそらせます。

   Thus, at each connection, each AS has one or more BGP speakers and
   one or more border gateways, and these BGP speakers and border
   gateways are all located on a shared network. Note that BGP speakers
   do not need to be a border gateway, and vice versa. Paths announced
   by a BGP speaker of one AS on a given connection are taken to be
   feasible for each of the border gateways of the other AS on the same
   connection, i.e. indirect neighbors are allowed.

したがって、各接続のときに、各ASには1人以上のBGPスピーカーと1境界門以上があります、そして、これらのBGPスピーカーと境界ゲートウェイは共用回線網にすべて位置しています。 BGPスピーカーが、境界ゲートウェイである必要でないことに注意してください、そして、逆もまた同様です。 同じ接続のときにそれぞれの他のASの境界ゲートウェイに可能になるように1ASのBGPスピーカーによって与えられた接続に発表された経路を取ります、すなわち、間接的な隣人を許容します。

   Much of the traffic carried within an AS either originates or
   terminates at that AS (i.e., either the source IP address or the
   destination IP address of the IP packet identifies a host on a
   network directly connected to that AS).  Traffic that fits this
   description is called "local traffic". Traffic that does not fit this
   description is called "transit traffic". A major goal of BGP usage is
   to control the flow of transit traffic.

ASの中で運ばれた交通の大部分は、おまけに、ASを溯源するか、または終えます(すなわち、IPパケットのソースIPアドレスか送付先IPアドレスのどちらかが直接そのASに接続されたネットワークでホストを特定します)。 この記述に合う交通は「ローカルの交通」と呼ばれます。 この記述に合わない交通は「トランジット交通」と呼ばれます。 BGP用法の主要な目標はトランジット交通の流れを制御することです。

   Based on how a particular AS deals with transit traffic, the AS may
   now be placed into one of the following categories:

どうトランジット交通に対処するかに基づいて、ASは現在、以下のカテゴリの1つに置かれるかもしれません:

      stub AS: an AS that has only a single connection to one other AS.
      Naturally, a stub AS only carries local traffic.

ASを引き抜いてください: 単独結合しか他の1ASまでないAS。 当然、スタッブASはローカルの交通を運ぶだけです。

BGP Working Group                                               [Page 3]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[3ページ]RFC1268アプリケーション

      multihomed AS: an AS that has connections to more than one other
      AS, but refuses to carry transit traffic.

multihomed AS: 接続が他の1ASまでありますが、トランジット交通を運ぶのを拒否するAS。

      transit AS: an AS that has connections to more than one other AS,
      and is designed (under certain policy restrictions) to carry both
      transit and local traffic.

トランジットAS: 接続が他の1ASまであって、トランジットとローカルの交通の両方を運ぶように設計されている(ある方針制限で)AS。

   Since a full AS path provides an efficient and straightforward way of
   suppressing routing loops and eliminates the "count-to-infinity"
   problem associated with some distance vector algorithms, BGP imposes
   no topological restrictions on the interconnection of AS's.

完全なAS経路がルーティング輪を抑圧する効率的で簡単な方法を提供して、いくつかの距離ベクトルアルゴリズムに関連している「無限カウント」問題を解決するので、BGPはASのインタコネクトにどんな位相的な制限も課しません。

3. BGP in the Internet

3. インターネットのBGP

   3.1 Topology Considerations

3.1 トポロジー問題

   The overall Internet topology may be viewed as an arbitrary
   interconnection of transit, multihomed, and stub AS's.  In order to
   minimize the impact on the current Internet infrastructure, stub and
   multihomed AS's need not use BGP.  These AS's may run other protocols
   (e.g., EGP) to exchange reachability information with transit AS's.
   Transit AS's using BGP will tag this information as having been
   learned by some method other than BGP. The fact that BGP need not run
   on stub or multihomed AS's has no negative impact on the overall
   quality of inter-AS routing for traffic not local to the stub or
   multihomed AS's in question.

総合的なインターネットトポロジーは、「マルチ-家へ帰」ったトランジットの任意のインタコネクトとして見なされて、ASのものを引き抜くかもしれません。 現在のインターネット基盤への影響を最小にするために、スタッブとmultihomed ASの必要性はBGPを使用しません。 ASのこれらのものは、トランジットASのものと可到達性情報を交換するために、他のプロトコル(例えば、EGP)を走らせるかもしれません。 トランジットASがBGPを使用すると、BGP以外の何らかの方法によって学習されたとしてこの情報はタグ付けをされるでしょう。 BGPがスタッブかmultihomed ASのものの上で作業する必要はないという事実はスタッブへのローカルでない交通かmultihomed ASのもののための相互ASルーティングの問題の総合的な品質に負の衝撃を全く持っていません。

   However, it is recommended that BGP may be used for stub and
   multihomed AS's as well, providing an advantage in bandwidth and
   performance over some of the currently used protocols (such as EGP).
   In addition, this would result in less need for the use of defaults
   and in better choices of Inter-AS routes for multihomed AS's.

しかしながら、また、BGPがスタッブとmultihomed ASのものに使用されるのは、お勧めです、現在中古のプロトコル(EGPなどの)のいくつか上で帯域幅と性能に利点を提供して。 さらに、これはデフォルトの使用とInter-ASルートの、より良い選択における、multihomed ASの、より少ない必要性をもたらすでしょう。

3.2 Global Nature of BGP

3.2 BGPのグローバルなネイチャー

   At a global level, BGP is used to distribute routing information
   among multiple Autonomous Systems. The information flows can be
   represented as follows:

グローバルなレベルでは、複数のAutonomous Systemsにルーティング情報を分配するのにBGPを使用します。以下の通り情報流れを表すことができます:

                 +-------+         +-------+
           BGP   |  BGP  |   BGP   |  BGP  |   BGP
        ---------+       +---------+       +---------
                 |  IGP  |         |  IGP  |
                 +-------+         +-------+

+-------+ +-------+ BGP| BGP| BGP| BGP| BGP---------+ +---------+ +--------- | IGP| | IGP| +-------+ +-------+

                 <-AS A-->         <--AS B->

<、-、B->としてのA(><)

   This diagram points out that, while BGP alone carries information

このダイヤグラムはそれを指摘しますが、BGPだけが情報を運びます。

BGP Working Group                                               [Page 4]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[4ページ]RFC1268アプリケーション

   between AS's, a combination of BGP and an IGP carries information
   across an AS.  Ensuring consistency of routing information between
   BGP and an IGP within an AS is a significant issue and is discussed
   at length later in Appendix A.

ASと、BGPの組み合わせとIGPの間では、ASの向こう側の情報は運ばれています。 ASの中のBGPとIGPの間のルーティング情報について一貫性があることを保証するのと、重要な問題であり、後で十分Appendix Aで議論します。

3.3 BGP Neighbor Relationships

3.3 BGP隣人関係

   The Internet is viewed as a set of arbitrarily connected AS's. BGP
   speakers in each AS communicate with each other to exchange network
   reachability information based on a set of policies established
   within each AS. Routers that communicate directly with each other via
   BGP are known as BGP neighbors. BGP neighbors can be located within
   the same AS or in different AS's. For the sake of discussion, BGP
   communications with neighbors in different AS's will be referred to
   as External BGP, and with neighbors in the same AS as Internal BGP.

インターネットは任意に接続されたASのものの1セットとして見なされます。 各ASのBGPスピーカーは、各ASの中で確立された1セットの方針に基づくネットワーク可到達性情報を交換するために互いにコミュニケートします。 互いと共にBGPを通して直接伝達するルータはBGP隣人として知られています。 BGP neighbors can be located within the same AS or in different AS's. For the sake of discussion, BGP communications with neighbors in different AS's will be referred to as External BGP, and with neighbors in the same AS as Internal BGP.

   There can be as many BGP speakers as deemed necessary within an AS.
   Usually, if an AS has multiple connections to other AS's, multiple
   BGP speakers are needed. All BGP speakers representing the same AS
   must give a consistent image of the AS to the outside. This requires
   that the BGP speakers have consistent routing information among them.
   These gateways can communicate with each other via BGP or by other
   means. The policy constraints applied to all BGP speakers within an
   AS must be consistent. Techniques such as using tagged IGP (see
   A.2.2) may be employed to detect possible inconsistencies.

ASの中で必要であると考えられるのと同じくらい多くのBGPスピーカーがいることができます。 通常、ASの他のものにASが複数の接続がいるなら、複数のBGPスピーカーが必要です。 同じASを表すすべてのBGPスピーカーがASの一貫したイメージを外部に与えなければなりません。 これは、BGPスピーカーが彼らの中に一貫したルーティング情報を持っているのを必要とします。 これらのゲートウェイはBGPを通して他の手段で互いと交信できます。 ASの中のすべてのBGPスピーカーに適用された方針規制は一貫しているに違いありません。 タグ付けをされたIGP(A.2.2を見る)を使用などなどのテクニックは、可能な矛盾を検出するのに使われるかもしれません。

   In the case of External BGP, the BGP neighbors must belong to
   different AS's, but share a common network. This common network
   should be used to carry the BGP messages between them. The use of BGP
   across an intervening AS invalidates the AS path information. An
   Autonomous System number must be used with BGP to specify which
   Autonomous System the BGP speaker belongs to.

External BGPの場合では、BGP隣人は異なったASのものに属さなければなりませんが、一般的なネットワークを共有してください。 この一般的なネットワークは、BGPメッセージをそれらに伝えるのに使用されるべきです。 介入しているASの向こう側のBGPの使用はAS経路情報を無効にします。 BGPスピーカーがどのAutonomous Systemに属すかを指定するのにBGPと共にAutonomous System番号を使用しなければなりません。

4. Policy Making with BGP

4. BGPとの政策立案

   BGP provides the capability for enforcing policies based on various
   routing preferences and constraints. Policies are not directly
   encoded in the protocol. Rather, policies are provided to BGP in the
   form of configuration information.

BGPは様々なルーティング好みと規制に基づく方針を実施するのに能力を提供します。 方針はプロトコルで直接コード化されません。 むしろ、設定情報の形で方針をBGPに提供します。

   BGP enforces policies by affecting the selection of paths from
   multiple alternatives, and by controlling the redistribution of
   routing information.  Policies are determined by the AS
   administration.

BGPは、複数の選択肢から経路の品揃えに影響して、ルーティング情報の再分配を制御することによって、方針を実施します。 方針はAS管理によって決定されます。

   Routing policies are related to political, security, or economic
   considerations. For example, if an AS is unwilling to carry traffic
   to another AS, it can enforce a policy prohibiting this. The

ルート設定方針は政治上の、または、安全か、経済の問題に関連します。 例えば、ASが別のASまで交通を運びたがっていないなら、それはこれを禁止する方針を実施できます。 The

BGP Working Group                                               [Page 5]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[5ページ]RFC1268アプリケーション

   following are examples of routing policies that can be enforced with
   the use of BGP:

以下に、BGPの使用で励行されることができるルーティング方針に関する例があります:

      1. A multihomed AS can refuse to act as a transit AS for other
         AS's.  (It does so by not advertising routes to networks other
         than those directly connected to it.)

1. multihomed ASは、ASの他のもののためのトランジットASとして機能するのを拒否できます。 (それは直接それに接続されたもの以外のネットワークにルートの広告を出さないことによって、そうします。)

      2. A multihomed AS can become a transit AS for a restricted set of
         adjacent AS's, i.e., some, but not all, AS's can use multihomed
         AS as a transit AS. (It does so by advertising its routing
         information to this set of AS's.)

2. multihomed ASはすなわち、隣接しているASのもの、何らかの制限されたセットのトランジットASになりますが、すべてなることができないで、ASのものはトランジットASとしてmultihomed ASを使用できます。 (それは広告でそうASのこのセットにルーティング情報をします。)

      3. An AS can favor or disfavor the use of certain AS's for
         carrying transit traffic from itself.

3. ASはあるASのもののそれ自体からトランジット交通を運ぶ使用を支持するか、または疎んじることができます。

   A number of performance-related criteria can be controlled with the
   use of BGP:

BGPの使用で多くの性能関連の評価基準を制御できます:

      1. An AS can minimize the number of transit AS's. (Shorter AS
         paths can be preferred over longer ones.)

1. ASはトランジットASの数を最小にすることができます。 (より長いものより短いAS経路を好むことができます。)

      2. The quality of transit AS's. If an AS determines that two or
         more AS paths can be used to reach a given destination, that
         AS can use a variety of means to decide which of the candidate
         AS paths it will use. The quality of an AS can be measured by
         such things as diameter, link speed, capacity, tendency to
         become congested, and quality of operation. Information about
         these qualities might be determined by means other than BGP.

2. トランジットASの品質。 ASが、与えられた目的地に達するのに2つ以上のAS経路を使用できることを決定するなら、そのASはそれが候補AS道のどれを使用するかを決めるさまざまな手段を使用できます。 操作の直径、リンク速度、容量、混雑するようになる傾向、および品質のようなものはASの品質を測定できます。 これらの品質に関する情報はBGP以外の手段で決定するかもしれません。

      3. Preference of internal routes over external routes.

3. 外部経路の上の内部のルートの好み。

   For consistency within an AS, equal cost paths, resulting from
   combinations of policies and/or normal route selection procedures,
   must be resolved in a consistent fashion.

ASの中の一貫性において、一貫したファッションで等しい費用経路(方針の組み合わせから生じる、そして/または、ノーマルルート選択手順)を決議しなければなりません。

   Fundamental to BGP is the rule that an AS advertises to its
   neighboring AS's only those routes that it uses. This rule reflects
   the "hop-by-hop" routing paradigm generally used by the current
   Internet.

BGPへの基本的はASがそれが使用するそれらのルートだけの隣接しているASのものに広告を出すという規則です。 この規則は一般に、現在のインターネットによって使用される「ホップごとの」ルーティングパラダイムを反映します。

5. Path Selection with BGP

5. BGPとの経路選択

   One of the major tasks of a BGP speaker is to evaluate different
   paths to a destination network from its border gateways at that
   connection, select the best one, apply applicable policy constraints,
   and then advertise it to all of its BGP neighbors at that same
   connection. The key issue is how different paths are evaluated and
   compared.

BGPスピーカーの主タスクの1つは、その同じ接続のときにBGP隣人のすべてにその接続のときに境界ゲートウェイと異なった経路を送信先ネットワークに評価して、最も良い方を選択して、適切な方針規制を適用して、次に、それの広告を出すことです。 主要な問題は異なった経路がどう評価されて、比較されるかということです。

BGP Working Group                                               [Page 6]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[6ページ]RFC1268アプリケーション

   In traditional distance vector protocols (e.g., RIP) there is only
   one metric (e.g., hop count) associated with a path. As such,
   comparison of different paths is reduced to simply comparing two
   numbers. A complication in Inter-AS routing arises from the lack of a
   universally agreed-upon metric among AS's that can be used to
   evaluate external paths. Rather, each AS may have its own set of
   criteria for path evaluation.

伝統的な距離ベクトルプロトコル(例えば、RIP)には、1つしかメートル法であることで(例えば、カウントを飛び越します)ありません。経路に関連しています。 そういうものとして、異なった経路の比較は単に2つの番号を比較するのに抑えられます。 Inter-ASルーティングにおける複雑さは外部の経路を評価するのに使用できるASのところで一般にメートル法で同意されたaの不足から起こります。 むしろ、各ASには、それ自身の経路評価の評価基準のセットがあるかもしれません。

   A BGP speaker builds a routing database consisting of the set of all
   feasible paths and the list of networks reachable through each path.
   For purposes of precise discussion, it's useful to consider the set
   of feasible paths for a given destination network. In most cases, we
   would expect to find only one feasible path. However, when this is
   not the case, all feasible paths should be maintained, and their
   maintenance speeds adaptation to the loss of the primary path. Only
   the primary path at any given time will ever be advertised.

BGPスピーカーはすべての実行可能経路のセットと各経路を通して届いているネットワークのリストから成るルーティングデータベースを築き上げます。 正確な議論の目的に、与えられた送信先ネットワークのために実行可能経路のセットを考えるのは役に立ちます。 多くの場合、私たちは、1つの実行可能経路だけを見つけると予想するでしょう。 しかしながら、これがそうでないときに、すべての実行可能経路が維持されるべきです、そして、彼らの維持は第一の経路の損失への適合を促進します。 今までに、その時々で第一の経路だけの広告を出すでしょう。

   The path selection process can be formalized by defining a partial
   order over the set of all feasible paths to a given destination
   network. One way to define this partial order is to define a function
   that maps each full AS path to a non-negative integer that denotes
   the path's degree of preference. Path selection is then reduced to
   applying this function to all feasible paths and choosing the one
   with the highest degree of preference.

すべての実行可能経路のセットの部分的な注文を与えられた送信先ネットワークと定義することによって、経路選択の過程を正式にすることができます。 この部分的なオーダーを定義する1つの方法は経路の好みの度合いを指示する非負の整数にそれぞれの完全なAS経路を写像する機能を定義することです。 そして、経路選択はこの機能をすべての実行可能経路に適用して、最も高度の好みでものを選ぶのに抑えられます。

   In actual BGP implementations, criteria for assigning degree of
   preferences to a path are specified in configuration information.

実際のBGP実現では、好みの度合いを経路に割り当てる評価基準は設定情報で指定されます。

   The process of assigning a degree of preference to a path can be
   based on several sources of information:

1段階の好みを経路に割り当てる過程は数個の情報筋に基づくことができます:

      1. Information explicitly present in the full AS path.

1. 完全なAS経路の明らかに現在の情報。

      2. A combination of information that can be derived from the full
         AS path and information outside the scope of BGP (e.g., policy
         routing constraints provided at configuration).

2. BGP(例えば構成で提供された方針ルーティング規制)の範囲の外で完全なAS経路と情報から得ることができる情報の組み合わせ。

   Possible criteria for assigning a degree of preference to a path are:

1段階の好みを経路に割り当てる可能な評価基準は以下の通りです。

      - AS count. Paths with a smaller AS count are generally better.

- ASは数えます。 一般に、より小さいASカウントがある経路は、より良いです。

      - Policy consideration. BGP supports policy-based routing based
        on the controlled distribution of routing information.  A BGP
        speaker may be aware of some policy constraints (both within
        and outside of its own AS) and do appropriate path selection.
        Paths that do not comply with policy requirements are not
        considered further.

- 方針の考慮。 BGPはルーティング情報の制御分配に基づく方針ベースのルーティングを支持します。 BGPスピーカーは、いくつかの方針規制を意識していて(それ自身のASの中、外)、適切な経路選択をするかもしれません。 方針要件に従わない経路がさらに考えられません。

BGP Working Group                                               [Page 7]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[7ページ]RFC1268アプリケーション

      - Presence or absence of a certain AS or AS's in the path. By
        means of information outside the scope of BGP, an AS may know
        some performance characteristics (e.g., bandwidth, MTU, intra-AS
        diameter) of certain AS's and may try to avoid or prefer them.

- 経路のあるASかASの存在か不在。 BGPの範囲の外の情報によって、ASは彼らをあるASのもののいくつかの性能の特性(例えば、帯域幅、MTU、イントラ-AS直径)を知って、避けようとするか、または好もうとするかもしれません。

      - Path origin. A path learned entirely from BGP (i.e., whose
        endpoint is internal to the last AS on the path is generally
        better than one for which part of the path was learned via EGP
        or some other means.

- 経路の起源。 経路は完全にBGPから学びました。(一般に、すなわち、だれの終点が経路の最後のASに内部であるかは、経路の一部がEGPを通して学習されたものかある他の手段より良いです。

      - AS path subsets. An AS path that is a subset of a longer AS
        path to the same destination should be preferred over the longer
        path.  Any problem in the shorter path (such as an outage) will
        also be a problem in the longer path.

- AS経路部分集合。 同じ目的地への、より長いAS経路の部分集合であるAS経路は、より長い経路より好まれるべきです。 また、より短い経路(供給停止などの)のどんな問題もより長い経路で問題になるでしょう。

      - Link dynamics. Stable paths should be preferred over unstable
        ones. Note that this criterion must be used in a very careful
        way to avoid causing unnecessary route fluctuation. Generally,
        any criteria that depend on dynamic information might cause
        routing instability and should be treated very carefully.

- 力学をリンクしてください。 安定路線は不安定なものより好まれるべきです。 不要なルート変動を引き起こすのを避ける非常に慎重な方法でこの評価基準を使用しなければならないことに注意してください。 一般に、動的情報に依存するどんな評価基準も、ルーティングの不安定性を引き起こすかもしれなくて、非常に慎重に扱われるべきです。

6. Required set of supported routing policies.

6. 必要なセットの支持されたルーティング方針。

   Policies are provided to BGP in the form of configuration
   information.  This information is not directly encoded in the
   protocol. Therefore, BGP can provides support for quite complex
   routing policies. However, it is not required for all BGP
   implementations to support such policies.

設定情報の形で方針をBGPに提供します。 この情報はプロトコルで直接コード化されません。 したがって、BGP缶はかなり複雑なルーティング方針のサポートを提供します。 しかしながら、すべてのBGP実現がそのような方針を支持するのにそれは必要ではありません。

   We are not attempting to standardize the routing policies that must
   be supported in every BGP implementation, we strongly encourage all
   implementors to support the following set of routing policies:

私たちは、あらゆるBGP実現で支持しなければならないルーティング方針を標準化するのを試みていなくて、すべての作成者が以下のセットのルーティング方針を支持するよう強く奨励します:

      1. BGP implementations should allow an AS to control announcements
         of BGP-learned routes to adjacent AS's.  Implementations should
         also support such control with at least the granularity of
         a single network.  Implementations should also support such
         control with the granularity of an autonomous system, where
         the autonomous system may be either the autonomous system that
         originated the route, or the autonomous system that advertised
         the route to the local system (adjacent autonomous system).

1. ASはBGP実現からBGPが学術的なルートの発表を隣接しているASのものに制御するはずであることができます。 また、実現は少なくともただ一つのネットワークの粒状でそのようなコントロールを支持するべきです。 また、実現は自律システム、自律システムがどこのルートを溯源した自律システムであるかもしれないか、そして、または自律システムの粒状があるローカルシステム(隣接している自律システム)にルートの広告を出したそのようなコントロールを支持するべきです。

      2. BGP implementations should allow an AS to prefer a particular
         path to a destination (when more than one path is available).
         This function should be implemented by allowing system
         administrators to assign "weights" to AS's, and making route
         selection process to select a route with the lowest "weight"
         (where "weight" of a route is defined as a sum of "weights" of

2. ASは目的地よりBGP実現で特定の経路を好むはずであることができます(1つ以上の経路が利用可能であるときに)。 この機能がシステム管理者が「重り」を割り当てるのを許容することによってASのものに実行されて、最も低い「重さ」があるルートを選択するためにルート選択の過程を作るべきである、(ルートの「重さ」が「重り」の合計と定義されるところ

BGP Working Group                                               [Page 8]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[8ページ]RFC1268アプリケーション

         all AS's in the AS_PATH path attribute associated with that
         route).

そのルートに関連しているAS_PATH経路属性におけるASのすべてのもの)

      3. BGP implementations should allow an AS to ignore routes with
         certain AS's in the AS_PATH path attribute.  Such function can
         be implemented by using technique outlined in (2), and by
         assigning "infinity" as "weights" for such AS's. The route
         selection process must ignore routes that have "weight" equal
         to "infinity".

3. ASはBGP実現でAS_PATH経路属性で、あるASのものがあるルートを無視するはずであることができます。 (2)に概説されたテクニックを使用して、ASのそのようなもののための「重り」として「無限」を割り当てることによって、そのような機能を実行できます。 ルート選択の過程は「無限」と等しい「重さ」を持っているルートを無視しなければなりません。

7. Conclusion

7. 結論

   The BGP protocol provides a high degree of control and flexibility
   for doing interdomain routing while enforcing policy and performance
   constraints and avoiding routing loops. The guidelines presented here
   will provide a starting point for using BGP to provide more
   sophisticated and manageable routing in the Internet as it grows.

方針と性能規制を実施して、輪を発送するのを避けている間、BGPプロトコルは高い統制度と柔軟性をinterdomainルーティングをするのに提供します。 ここに提示されたガイドラインは成長するとき、より洗練されて処理しやすいルーティングをインターネットに提供するのにBGPを使用するための出発点を提供するでしょう。

Appendix A. The Interaction of BGP and an IGP

付録A.はBGPとIGPの相互作用です。

   This section outlines methods by which BGP can exchange routing
   information with an IGP. The methods outlined here are not proposed
   as part of the standard BGP usage at this time.  These methods are
   outlined for information purposes only.  Implementors may want to
   consider these methods when importing IGP information.

このセクションはBGPがルーティング情報をIGPと交換できる方法を概説します。 ここに概説された方法はこのとき、標準のBGP用法の一部として提案されません。 これらの方法は情報目的だけのために概説されています。 IGP情報を輸入するとき、作成者はこれらの方法を考えたがっているかもしれません。

   This is general information that applies to any generic IGP.
   Interaction between BGP and any specific IGP is outside the scope of
   this section.  Methods for specific IGP's should be proposed in
   separate documents.  Methods for specific IGP's could be proposed for
   standard usage in the future.

これはどんな一般的なIGPにも適用される一般情報です。 このセクションの範囲の外にBGPとどんな特定のIGPとの相互作用もあります。 特定のIGPのもののための方法は別々のドキュメントで提案されるべきです。 将来、標準的用法のために特定のIGPのもののための方法を提案できました。

Overview

概観

   By definition, all transit AS's must be able to carry traffic which
   originates from and/or is destined to locations outside of that AS.
   This requires a certain degree of interaction and coordination
   between BGP and the Interior Gateway Protocol (IGP) used by that
   particular AS. In general, traffic originating outside of a given AS
   is going to pass through both interior gateways (gateways that
   support the IGP only) and border gateways (gateways that support both
   the IGP and BGP). All interior gateways receive information about
   external routes from one or more of the border gateways of the AS via
   the IGP.

定義上、すべてのトランジットASによって由来する交通は運ぶことができなければならない、そして/または、運命づけられた、そのASにおける外の位置。 これはゲートウェイプロトコル(IGP)がその特定のASで使用したBGPとInteriorの間のある度の相互作用とコーディネートを必要とします。 一般に、与えられたASの外で由来する交通は内部のゲートウェイ(IGPだけを支持するゲートウェイ)と境界ゲートウェイ(IGPとBGPの両方を支持するゲートウェイ)の両方を通り抜けるでしょう。 内部のゲートウェイが外部であることの形で情報を受け取るすべてがIGPを通して境界の1つ以上からASのゲートウェイを発送します。

   Depending on the mechanism used to propagate BGP information within a
   given AS, special care must be taken to ensure consistency between
   BGP and the IGP, since changes in state are likely to propagate at

メカニズムによるのは以前は、よく状態の変化がありそうであるので与えられたASの中では、BGPとIGPの間の一貫性を確実にするために特別な注意を払わなければならないという伝播するBGP情報を伝播していました。

BGP Working Group                                               [Page 9]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[9ページ]RFC1268アプリケーション

   different rates across the AS. There may be a time window between the
   moment when some border gateway (A) receives new BGP routing
   information which was originated from another border gateway (B)
   within the same AS, and the moment the IGP within this AS is capable
   of routing transit traffic to that border gateway (B). During that
   time window, either incorrect routing or "black holes" can occur.

ASの向こう側の異なったレート。 ある境界ゲートウェイ(A)が同じASの中にもう1境界門(B)から溯源された新しいBGPルーティング情報を受け取って、このASの中のIGPはルーティングトランジット交通ができる瞬間をその境界ゲートウェイ(B)に受け取る瞬間の間には、タイムウィンドウがあるかもしれません。 そのタイムウィンドウの間、不正確なルーティングか「ブラックホール」のどちらかが起こることができます。

   In order to minimize such routing problems, border gateway (A) should
   not advertise a route to some exterior network X via border gateway
   (B) to all of its BGP neighbors in other AS's until all the interior
   gateways within the AS are ready to route traffic destined to X via
   the correct exit border gateway (B). In other words, interior routing
   should converge on the proper exit gateway before/advertising routes
   via that exit gateway to other AS's.

そのようなルーティング問題を最小にするために、ASの中のすべての内部のゲートウェイが正しい出口境界ゲートウェイ(B)を通してXに運命づけられた交通を発送する準備ができるまで、境界ゲートウェイ(A)はASの他のところにBGP隣人のすべてへの境界ゲートウェイ(B)を通して何らかの外のネットワークXにルートの広告を出すはずがありません。 言い換えれば、内部のルーティングはASの他のものへのその出口ゲートウェイを通して/広告ルートの前で適切な出口ゲートウェイに集まるべきです。

A.2 Methods for Achieving Stable Interactions

安定した相互作用を達成するためのA.2方法

   The following discussion outlines several techniques capable of
   achieving stable interactions between BGP and the IGP within an
   Autonomous System.

以下の議論はAutonomous Systemの中でBGPとIGPとの安定した相互作用を達成できるいくつかのテクニックについて概説します。

A.2.1 Propagation of BGP Information via the IGP

IGPを通したBGP情報のA.2.1伝播

   While BGP can provide its own mechanism for carrying BGP information
   within an AS, one can also use an IGP to transport this information,
   as long as the IGP supports complete flooding of routing information
   (providing the mechanism to distribute the BGP information) and
   onepass convergence (making the mechanism effectively atomic). If an
   IGP is used to carry BGP information, then the period of
   desynchronization described earlier does not occur at all, since BGP
   information propagates within the AS synchronously with the IGP, and
   the IGP converges more or less simultaneously with the arrival of the
   new routing information. Note that the IGP only carries BGP
   information and should not interpret or process this information.

また、BGPがASの中でBGP情報を運ぶのにそれ自身のメカニズムを提供できる間、1つはこの情報を輸送するのにIGPを使用できます、IGPがルーティング情報(BGP情報を分配するためにメカニズムを提供する)とonepass集合の完全な氾濫を支持する(メカニズムを事実上、原子にして)限り。 IGPがBGP情報を運ぶのに使用されるなら、より早く説明された脱同期化の期間は全く起こりません、BGP情報がIGPと共にASの中で同時伝播されて、IGPが同時に新しいルーティング情報の到着で多少一点に集まるので。 IGPだけがこの情報をBGP情報を運んで、解釈するはずがありませんし、また処理するはずがないことに注意してください。

A.2.2  Tagged Interior Gateway Protocol

A.2.2は内部のゲートウェイプロトコルにタグ付けをしました。

   Certain IGPs can tag routes exterior to an AS with the identity of
   their exit points while propagating them within the AS. Each border
   gateway should use identical tags for announcing exterior routing
   information (received via BGP) both into the IGP and into Internal
   BGP when propagating this information to other border gateways within
   the same AS. Tags generated by a border gateway must uniquely
   identify that particular border gateway--different border gateways
   must use different tags.

あるIGPsはASの中でそれらを伝播している間、ASへの外のルートに彼らのエキジットポイントのアイデンティティをタグ付けできます。 それぞれの境界ゲートウェイは、同じASの中で他の境界ゲートウェイにこの情報を伝播するとき外のルーティング情報(BGPを通して、受信する)をIGPの中と、そして、Internal BGPの中に発表するのに同じタグを使用するはずです。 境界ゲートウェイで発生するタグは唯一その特定の境界ゲートウェイを特定しなければなりません--異なった境界ゲートウェイは異なったタグを使用しなければなりません。

   All Border Gateways within a single AS must observe the following two
   rules:

独身のASの中のすべてのBorder Gatewaysが以下の2つの規則を守らなければなりません:

BGP Working Group                                              [Page 10]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[10ページ]RFC1268アプリケーション

      1. Information received via Internal BGP by a border gateway A
         declaring a network to be unreachable must immediately be
         propagated to all of the External BGP neighbors of A.

1. すぐに、ネットワークが手が届かないと宣言しながら境界ゲートウェイAのそばのInternal BGPを通して受け取られた情報をAのExternal BGP隣人のすべてに伝播しなければなりません。

      2. Information received via Internal BGP by a border gateway A
         about a reachable network X cannot be propagated to any of
         the External BGP neighbors of A unless/until A has an IGP
         route to X and both the IGP and the BGP routing information
         have identical tags.

2. Aまでの/がIGPルートをXに持っていない場合、境界ゲートウェイAのそばのInternal BGPを通して届いているネットワークXに関して受け取られた情報はAのExternal BGP隣人のどれかに伝播できません、そして、IGPとBGPルーティング情報の両方には、同じタグがあります。

   These rules guarantee that no routing information is announced
   externally unless the IGP is capable of correctly supporting it. It
   also avoids some causes of "black holes".

これらの規則は、IGPが正しくそれを支持できないならルーティング情報が全く外部的に発表されないのを保証します。 また、それは「ブラックホール」のいくつかの原因を避けます。

   One possible method for tagging BGP and IGP routes within an AS is to
   use the IP address of the exit border gateway announcing the exterior
   route into the AS. In this case the "gateway" field in the BGP UPDATE
   message is used as the tag.

ASの中でBGPとIGPルートにタグ付けをするための1つの可能な方法は外のルートをASに発表する出口境界ゲートウェイのIPアドレスを使用することです。 この場合、BGP UPDATEメッセージの「ゲートウェイ」分野はタグとして使用されます。

A.2.3 Encapsulation

A.2.3カプセル化

   Encapsulation provides the simplest (in terms of the interaction
   between the IGP and BGP) mechanism for carrying transit traffic
   across the AS. In this approach, transit traffic is encapsulated
   within an IP datagram addressed to the exit gateway. The only
   requirement imposed on the IGP by this approach is that it should be
   capable of supporting routing between border gateways within the same
   AS.

カプセル化は最も簡単な(IGPとBGPとの相互作用に関する)メカニズムをASの向こう側にトランジット交通を運ぶのに提供します。 このアプローチでは、トランジット交通は出口ゲートウェイに記述されたIPデータグラムの中に要約されます。 このアプローチでIGPに課された唯一の要件は同じASの中で境界ゲートウェイの間で掘るのを支持できるべきであるということです。

   The address of the exit gateway A for some exterior network X is
   specified in the BGP identifier field of the BGP OPEN message
   received from gateway A via Internal BGP by all other border gateways
   within the same AS. In order to route traffic to network X, each
   border gateway within the AS encapsulates it in datagrams addressed
   to gateway A. Gateway A then performs decapsulation and forwards the
   original packet to the proper gateway in another AS

何らかの外のネットワークXのための出口ゲートウェイAのアドレスは同じASの中に他のすべての境界ゲートウェイのそばのInternal BGPを通したゲートウェイAから受け取られたBGP OPENメッセージのBGP識別子分野で指定されます。 ネットワークXに交通を発送するために、ASの中のゲートウェイがそれを要約するデータグラムがゲートウェイA.ゲートウェイAに記述した各境界は、別のASの適切なゲートウェイに次に、被膜剥離術を実行して、オリジナルのパケットを送ります。

   Since encapsulation does not rely on the IGP to carry exterior
   routing information, no synchronization between BGP and the IGP is
   required.

カプセル化が外のルーティング情報を運ぶためにIGPを当てにしないので、BGPとIGPの間の同期は全く必要ではありません。

   Some means of identifying datagrams containing encapsulated IP, such
   as an IP protocol type code, must be defined if this method is to be
   used.

この方法が使用されていることであるならIPプロトコルタイプコードなどの要約のIPを含むデータグラムを特定するいくつかの手段を定義しなければなりません。

   Note, that if a packet to be encapsulated has length that is very
   close to the MTU, that packet would be fragmented at the gateway that
   performs encapsulation.

要約されるべきパケットに長さがあるならそれがMTUの非常に近くにいるというメモ、そのパケットはカプセル化を実行するゲートウェイで断片化されるでしょう。

BGP Working Group                                              [Page 11]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[11ページ]RFC1268アプリケーション

A.2.4  Other Cases

A.2.4他のケース

   There may be AS's with IGPs which can neither carry BGP information
   nor tag exterior routes (e.g., RIP). In addition, encapsulation may
   be either infeasible or undesirable. In such situations, the
   following two rules must be observed:

BGP情報を運ばないで、外のルートにタグ付けをすることができないIGPs(例えば、RIP)があるASのものがあるかもしれません。 さらに、カプセル化は、実行不可能であるか、または望ましくないかもしれません。 そのような状況で、以下の2つの規則を守らなければなりません:

      1. Information received via Internal BGP by a border gateway A
         declaring a network to be unreachable must immediately be
         propagated to all of the External BGP neighbors of A.

1. すぐに、ネットワークが手が届かないと宣言しながら境界ゲートウェイAのそばのInternal BGPを通して受け取られた情報をAのExternal BGP隣人のすべてに伝播しなければなりません。

      2. Information received via Internal BGP by a border gateway A
         about a reachable network X cannot be propagated to any of
         the External BGP neighbors of A unless A has an IGP route to
         X and sufficient time (holddown) has passed for the IGP routes
         to have converged.

2. AがIGPルートをXに持っていない場合、境界ゲートウェイAのそばのInternal BGPを通して届いているネットワークXに関して受け取られた情報はAのExternal BGP隣人のどれかに伝播できません、そして、十分な時間(留め具)は一点に集まったようにIGPルートに適用しました。

   The above rules present necessary (but not sufficient) conditions for
   propagating BGP routing information to other AS's. In contrast to
   tagged IGPs, these rules cannot ensure that interior routes to the
   proper exit gateways are in place before propagating the routes other
   AS's.

上の規則はBGPルーティング情報を他のASに伝播するための必要で(十分でない)の状態を提示します。 タグ付けをされたIGPsと対照して、これらの規則は、他のルートASを伝播する前に、適切な出口ゲートウェイへの内部のルートが適所にあるのを確実にすることができません。

   If the convergence time of an IGP is less than some small value X,
   then the time window during which the IGP and BGP are unsynchronized
   is less than X as well, and the whole issue can be ignored at the
   cost of transient periods (of less than length X) of routing
   instability. A reasonable value for X is a matter for further study,
   but X should probably be less than one second.

IGPの集合時間が以下であるなら、IGPとBGPが非連動するタイムウィンドウはまた、Xより何らかの小さい値Xより少ないです、そして、一時的な期間(長さX以下の)のルーティングの不安定性の費用で全体の問題は無視できます。 Xのための適正価値はさらなる研究への問題ですが、Xはたぶん1秒未満であるべきです。

   If the convergence time of an IGP cannot be ignored, a different
   approach is needed. Mechanisms and techniques which might be
   appropriate in this situation are subjects for further study.

IGPの集合時間を無視できないなら、異なるアプローチが必要です。 この状況で適切であるかもしれないメカニズムとテクニックはさらなる研究への対象です。

References

参照

   [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
       3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
       Corp., October 1991.

[1] ロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP3)」、RFC1267、コクチマスSystems、T.J.ワトソン研究所、IBM社(1991年10月)。

   [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
       Merit/NSFNET, June 1989.

[2] ブラウン、H-W.、「方針のベースのルート設定のモデル」、RFC1104、長所/NSFNET、1989年6月。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

BGP Working Group                                              [Page 12]

RFC 1268           Application of BGP in the Internet       October 1991

インターネット1991年10月のBGPのBGP作業部会[12ページ]RFC1268アプリケーション

Authors' Addresses

作者のアドレス

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598

   Phone:  (914) 945-3896
   EMail: yakov@watson.ibm.com

以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com

   Phill Gross
   Advanced Network and Services (ANS)
   100 Clearbrook Road
   Elmsford, NY 10523

フィル・総計の高度なネットワークとサービス(ANS)100Clearbrook Roadエルムスフォード、ニューヨーク 10523

   Phone: (914) 789-5300
   Email: pgross@NIS.ANS.NET

以下に電話をしてください。 (914) 789-5300 メールしてください: pgross@NIS.ANS.NET

   IETF BGP WG mailing list: iwg@rice.edu
   To be added: iwg-request@rice.edu

IETF BGP WGメーリングリスト: 加えられるべき iwg@rice.edu : iwg-request@rice.edu

BGP Working Group                                              [Page 13]

BGP作業部会[13ページ]