Network Working Group E. Chen
Request for Comments: 2519 Cisco
Category: Informational J. Stewart
Juniper
February 1999
A Framework for Inter-Domain Route Aggregation
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing.
この文書では、ドメイン間のルート集約のための枠組みを提示し、このフレームワーク「を実装」例のルータの設定を示します。このフレームワークは、柔軟であり、それは、ルーティングドメイン内ならびに上流のプロバイダに向かって両方、ソースによって凝集の哲学を強調したように適切に拡張され、それはまた、強く、プロバイダのバランスをとるために「無エクスポート」BGPコミュニティの使用を奨励します加入者スケーラブルなドメイン間ルーティングのためのインターネットの必要性と、より詳細なルーティング情報のために必要。
The need for route aggregation has long been recognized. Route aggregation is good as it reduces the size, and slows the growth, of the Internet routing table. Thus, the amount of resources (e.g., CPU and memory) required to process routing information is reduced and route calculation is sped up. Another benefit of route aggregation is that route flaps are limited in number, frequency and scope, which saves resources and makes the global Internet routing system more stable.
ルート集約の必要性は長い間認識されています。それはサイズを削減し、インターネットルーティングテーブルの成長を、減速としてルート集約は良いです。したがって、ルーティング情報を処理するために必要なリソースの量（例えば、CPUおよびメモリ）が低減され、ルート計算が高速化されます。ルート集約の別の利点は、ルートフラップがリソースを節約し、グローバルインターネットルーティングシステムをより安定させ数、周波数および範囲に限定されることです。
Since CIDR (Classless Inter-Domain Routing) [2] was introduced, significant progress has been made on route aggregation, particularly in the following two areas:
CIDR（クラスレスドメイン間ルーティング）[2]を導入し、大きな進展は、特に次の二つの領域では、ルート集約になされたものであり、導入されたバージョン：
- Formulation and implementation of IP address allocation policies by the top registries that conform to the CIDR principles [1].
- CIDR原則に準拠トップレジストリによって処方およびIPアドレス割り当てポリシーの実装[1]。
This policy work is the cornerstone which makes efficient route aggregation technically possible.
このポリシー作品は、効率的な経路集約が技術的に可能にする基礎となるものです。
- Route aggregation by large (especially "Tier 1") providers. To date, the largest reductions in the size of the routing table have resulted from efficient aggregation by large providers.
- 大（特に「ティア1」）プロバイダによる経路集約。現在までに、ルーティングテーブルのサイズで最大の削減は大きなプロバイダによって効率的に集約から生じました。
However, the ability of various levels of the global routing system to implement efficient aggregation schemes varies widely. As a result, the size and growth rate of the Internet routing table, as well as the associated route computation required, remain major issues today. To support Internet growth, it is important to maximize the efficiency of aggregation at all levels in the routing system.
しかし、効率的な集計方式を実装するためのグローバルルーティングシステムの様々なレベルの能力は大きく異なります。その結果、インターネットルーティングテーブルのサイズと成長率だけでなく、必要な関連したルート計算は、今日の主要な課題のまま。インターネットの成長をサポートするために、ルーティングシステム内のすべてのレベルでの集計の効率を最大にすることが重要です。
Because of the current size of the routing system and its dynamic nature, the first step towards this goal is to establish a clearly defined framework in which scaleable inter-domain route aggregation can be realized. The framework described in this document is based on the predominant and current experience in the Internet. It emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers. The framework also strongly encourages the use of the "no-export" BGP community to balance the providersubscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. The advantages of this framework include the following:
なぜならルーティングシステムの現在のサイズとその動的性質のため、この目標に向けた最初のステップは、スケーラブルなドメイン間ルート集約を実現することができる明確に定義されたフレームワークを確立することです。この文書で説明したフレームワークは、インターネットでの優勢と現在の経験に基づいています。これは、ルーティングドメイン内ならびに上流のプロバイダに向かって両方、ソースによって凝集の哲学を強調しています。また、フレームワークは強く、スケーラブルなドメイン間ルーティングのためのインターネットの必要性と、より詳細なルーティング情報についてprovidersubscriberの必要性のバランスを取るために「ノー輸出」BGPコミュニティの使用を奨励しています。このフレームワークの利点は、以下のものがあります。
- Route aggregation is done in a distributed fashion, with emphasis on aggregation by the party or parties injecting the aggregatable routing information into the global mesh.
- ルート集約は、グローバルメッシュに集約ルーティング情報を注入する当事者によって集約に重点を置いて、分散方式で行われます。
- The flexibility of a routing domain to be able to inject more granular routing information to an adjacent domain to control the resulting traffic patterns, without having an impact on the global routing system.
- ルーティングドメインの柔軟性がグローバルルーティングシステムに影響を与えることなく、得られたトラフィックパターンを制御するために、隣接するドメインに複数の粒状のルーティング情報を注入することができるようにします。
In addition to describing the philosophy, we illustrate it by presenting sample configurations. IPv4 prefixes, BGP4 and ASs are used in examples, though the principles are applicable to inter-domain route aggregation in general.
哲学を説明することに加えて、我々は、コンフィギュレーション例を提示することによって、それを説明します。原理は、一般的にドメイン間ルート集約に適用されてもIPv4のプレフィックス、BGP4とお尻は、実施例で使用されています。
Address allocation policies and technologies to renumber entire networks, while very relevant to the realization of successful and sustained inter-domain routing, are not the focus of this document. The references section contains pointers to relevant documents [8, 9, 11, 12].
成功と持続的なドメイン間ルーティングの実現に非常に関連しながら、ネットワーク全体の番号を変更するには、アドレス割り当てポリシーおよび技術は、この文書の焦点ではありません。参照部[8、9、11、12]関連文書へのポインタを含みます。
The framework of inter-domain route aggregation we are proposing can be summarized as follows:
次のように我々が提案しているドメイン間のルート集約の枠組みをまとめることができます。
- Aggregation from the originating AS
- 発信元から集約AS
That is, in its outbound route announcements, each AS aggregates the BGP routes originated by itself, by dedicated AS and by private-ASs [10]. ("Routes originated by an AS" refers to routes which have that AS first in the AS path attribute. For example, routes statically configured and injected into BGP fall into this category.)
すなわち、各ASは、専用ASにより、専用尻[10]により、自身が発信BGPルートを集約し、そのアウトバウンド経路アナウンスです。 （「ASから発信ルートは、」AS最初のASパス属性である。例えば、静的BGPに設定され、注入されたルートは、このカテゴリに分類することを有するルートを指します。）
This framework does not depend on "proxy aggregation" which refers to route aggregation done by an AS other than the originating AS. This preserves the capability of a multi-homed site to control the granularity of routing information injected into the global routing system. Since proxy aggregation involves coordination among multiple organizations, the complexity of doing proxy aggregation increases with the number of parties involved in the coordination. The complexity, in turn, impacts the practicality of proxy aggregation.
このフレームワークは、AS発信以外などの他によって行われ、ルート集約を指す「プロキシ集合」には依存しません。これは、グローバルルーティングシステムに注入ルーティング情報の細分性を制御するマルチホームサイトの能力を保持します。プロキシ集約は複数の組織間の調整を必要とするので、プロキシ集約を行うことの複雑さは、コーディネートに関わる関係者の数とともに増加します。複雑、順番に、影響プロキシ凝集の実用性。
An AS shall always originate via a stable mechanism (e.g., static route configuration) the BGP routes for the large aggregates from which it allocates addresses to customers. This ensures that it is safe for its customers to use BGP "no-export".
ASは、常に安定した機構（例えば、静的ルート設定）を介して、それが顧客にアドレスを割り当て、そこから大きな凝集物のBGPルートを発信しなければなりません。これは、顧客がBGP「ノー輸出」を使用することが安全であることを保証します。
- Using BGP community "no-export" toward upstream providers
- 上流のプロバイダに向けて、「何の輸出を」BGPコミュニティを使用していません
That is, in its route announcements toward its upstream provider, an AS tags the BGP community "no-export" to routes it originates that do not need to be propagated beyond its upstream provider (e.g., prefixes allocated by the upstream provider).
それは、その上流プロバイダに向けてそのルートの発表では、ASは、その上流のプロバイダを超えて伝播する必要がないことを発信ルートにBGPコミュニティ「ノー輸出」タグ（例えば、上流プロバイダによって割り当てられたプレフィックス）。
This framework is illustrated in Figure 1. A "Tier 1" provider does not use "no-export" in its announcement as it does not have an upstream provider. However, it shall aggregate the routes it originates in its outbound announcements towards both peer providers and customers. An AS with an upstream provider shall aggregate the routes it originates and use "no-export" toward its upstream provider for routes that do not need to be propagated beyond its provider's AS. This recursion shall apply to all levels of the routing hierarchy.
このフレームワークは、上流プロバイダを持っていないとして「ティア1」プロバイダは、そのアナウンスにて「Noエクスポート」を使用しない図1のAに示されています。しかし、それはピア・プロバイダと顧客の両方に向けて発信アナウンスメントに起因するルートを集約するものとします。上流プロバイダとのASそれが発信するルートを集約し、そのプロバイダのASを超えて伝播する必要はありませんルートのその上流プロバイダに向けて、「何の輸出」を使用してはなりません。この再帰は、ルーティング階層のすべてのレベルに適用されるものとします。
Tier 1
+-- Provider <--+
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| ^ o uses "no-export" if appropriate
|
+---> Tier 2 <--+
Provider |
V |
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| | o uses "no-export" if appropriate
| |
| ^
-> Customer AS
Figure 1
図1
This framework scales well as aggregation is done at all levels of the routing system. It is flexible because the originating AS controls whether routes of finer granularity are injected to, and/or propagated by, its upstream provider. It facilitates multi-homing without compromising route aggregation.
凝集がルーティングシステムのすべてのレベルで行われているように、このフレームワークは、適切に拡張されます。それは柔軟であるため、より細かい粒度のルートがに注入、及び/又はその上流プロバイダによって伝播されるかどうかをコントロールとして発信。これは、ルート集約を損なうことなく、マルチホーミングを容易にします。
This framework is detailed in the following sections.
このフレームワークは、以下のセクションで詳述されています。
It has been well recognized that address allocation and address renumbering are keys to containing the growth of the Internet routing table [1, 2, 8, 9, 11, 12].
よくアドレス割り当ておよびアドレス番号を付け替えるがインターネットルーティングテーブルの成長[1、2、8、9、11、12]を含有する鍵であることが認識されています。
Although the strategies discussed in this document do not assume a perfect address allocation, it is strongly urged that an AS receive allocation from its upstream service providers' address block.
この文書で説明する戦略は完璧なアドレス割り当てを負いませんが、強くASは、その上流のサービスプロバイダのアドレスブロックから割り当てを受けることを促しています。
To reduce the number of routes that need to be injected into an AS, there are a couple of principles that shall be followed:
ASに注入する必要があるルートの数を減らすために、従わなければならない原則のカップルがあります：
- Carry in its BGP table the large route block allocated from its upstream provider or an address registry (e.g., InterNIC, RIPE, APNIC). This can be done by either static configuration of the large block or by aggregating more specific BGP routes. The former is recommended as it does not depend on other routes.
- そのBGPテーブルにその上流プロバイダまたはアドレスレジストリ（例えば、InterNICに、RIPE、APNIC）から割り当てられた大ルートブロックを運びます。これは、大きなブロックの静的な構成によって、またはそれ以上の特定のBGPルートを集約することによって行うことができます。それは、他の経路に依存しないよう前者が推奨されます。
- Allocate sub-blocks to the access routers where further allocation is done. That is, the address allocation shall be done such that only a few, less specific routes (instead of many more, specific ones) need to be known to the other routers within the AS.
- さらに、割り当てが行われ、アクセスルータにサブブロックを割り当てます。すなわち、アドレス割り当てはわずか数、より少ない特定のルート（代わりに、より多くの、特定のもの）はAS内の他のルータに知られる必要があるように行われるものとされています。
For example, a prefix of /17 can be further allocated to different access routers as /20s which can then be allocated to customers connected to different interfaces on that router (as shown in Figure 2). Then in general only the /20 needs to be injected into the whole AS. Exceptions need to be made for multi-homed static routes.
（図2に示されるように）、そのルータ上の異なるインターフェイスに接続された顧客に割り当て可能な20S /ように、例えば、/ 17の接頭辞は、異なるアクセスルータに割り当てることができます。その後のみ/ 20ニーズ一般的には全体のASに注入されます。例外は、マルチホームの静的ルートのためになされる必要があります。
access router
+------------+
| x.x.x.x/20 |
+------------+
| | |
| | |
/24 /22 /25
Figure 2
図2
It is noted that rehoming of customers without renumbering even within the same AS may lead to injection of more specific routes. However, in general the more-specifics do not need to be advertised outside of that AS. Such routes can either be tagged with the BGP community "no-export" or filtered out by a prefix-based filter to prevent them from being advertised out.
それも、同じAS内再番号付けずに顧客のリホームがより具体的なルートの注入につながる可能性があることに留意されたいです。しかし、一般的にはより多くの-具体的には、そのASの外に広告する必要はありません。このようなルートは、どちらかのBGPコミュニティ「非輸出」でタグ付けやアウト公示されているからそれらを防ぐために、プレフィックスベースのフィルタによってフィルタリングすることができます。
There are at least two types of routes that need to be advertised by an AS: routes originated by the AS and routes originated by its BGP customers. An AS may need to advertise full routes to certain BGP customers, in which case the routing announcements include routes originated by non-customer ASs. Clearly an AS can, and should, safely aggregate the routes originated by itself and by its BGP customers multi-homed only to it (using, e.g., the dedicated-AS and by the private-AS mechanism [10]) in its outbound announcement. But it is far more dangerous to aggregate routes originated by customer ASs due to multi-homing.
ASによって発信ルートとそのBGPの顧客によって発信ルート：ASによってアドバタイズする必要があるルートのうち少なくとも2つのタイプがあります。 ASは、ルーティングアナウンスが非顧客のASが発信したルートを含め、その場合には、特定のBGP顧客への完全なルートを、アドバタイズする必要があるかもしれません。明らかにASことができ、そして、安全に自身が発信したルートを集約し、そのBGPの顧客によってのみ、それにマルチホーム（使用して、例えば、専用の-ASを、民間-ASメカニズム[10]による）する必要があり、そのアウトバウンドの発表で。しかし、それはマルチホーミングによる顧客のASによって発信集約ルートにはるかに危険です。
However, there are several cases in which a route originated by a BGP customer (other than using the dedicated AS or private AS) does not need to be advertised out by its upstream providers. For example,
しかし、その上流プロバイダによって宣伝する必要はありません（AS専用を使用するか、またはプライベートAS以外の）ルートがBGPの顧客によって発信されているいくつかの例があります。例えば、
- The route is a more-specific of the upstream provider's block. However, the customer is either singly homed; or its connection to this particular upstream provider is used for backup only.
- 経路は、上流プロバイダのブロックの、より特異的です。しかし、顧客は単独ホームです。あるいは、この特定の上流のプロバイダへの接続のみをバックアップするために使用されます。
- The more-specifics of a larger block are announced by the customer in order to balance traffic over the multiple links to the upstream provider.
- 大きなブロックのより具体的には、上流プロバイダへの複数のリンクを介してトラフィックを分散するために、顧客が発表されています。
Our approach to suppress such routes is to give control to the ASs that originate the more-specifics (as seen by its upstream providers) and let them tag the BGP community "no-export" to the appropriate routes.
そのような経路を抑制するための我々のアプローチは、より多くの-詳細を発信（その上流プロバイダが見られるように）、それらを適切なルートにBGPコミュニティ「ノー輸出を」タグ付けましょう尻から制御を与えることです。
The BGP community "no-export" is a well known BGP community [6, 7]. A route with this attribute is not propagated beyond an AS boundary. So, if a route is tagged with this community in its announcement to an upstream provider and is accepted by the upstream provider, the route will not be announced beyond the upstream provider's AS. This achieves the goal of suppressing the more-specifics in the upstream provider's outbound announcement.
BGPコミュニティ「ノー輸出は、」よく知られてBGPコミュニティである[6、7]。この属性を持つルートはAS境界を超えて伝播されません。ルートが上流のプロバイダにその発表の中で、このコミュニティでタグ付けされており、上流プロバイダによって受け入れられているのであれば、ルートは上流プロバイダのASを超えて発表されることはありません。これは、上流プロバイダのアウトバウンドの発表により、詳細を抑制するという目標を達成します。
In this framework, the BGP community "no-export" shall be tagged to routes that are to be advertized to, but not propagated by, its upstream provider. They may include routes allocated out of its upstream provider's block or the more specific routes announced to its upstream provider for the purpose of load balancing. This aggregation strategy can be implemented via prefix-based filtering as shown in the example of Section 5.
このフレームワークでは、BGPコミュニティ「ノー輸出は」をアピールすることになっているルートにタグ付けされなければならないが、その上流プロバイダによって伝達されません。彼らは、その上流プロバイダのブロックのうち、割り当てられたルートや負荷分散を目的としたその上流プロバイダに発表された、より具体的なルートを含んでいてもよいです。第5の例に示すように、この集約戦略は、プレフィックスベースのフィルタリングを介して実施することができます。
For its own protection, a downstream AS shall announce only its own routes and its customer routes to its upstream providers. Thus, the outbound routing announcement and aggregation policy can be expressed as follows:
独自の保護のために、下流のASは、その上流のプロバイダにのみ、独自のルートとその顧客のルートを公表しなければなりません。次のようにこのように、アウトバウンドルーティングアナウンスと集約ポリシーを表すことができます。
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
自身から発信ルートの/専用-AS /プライベート-AS：「ノー輸出」適切とタグ、および大規模なブロックを宣伝し、より多くの-仕様を抑制
For routes originated by customer ASs: advertise to upstream ASs
顧客のASによって発信ルートの場合：尻を上流側に宣伝
For any other routes: do not advertise to upstream ASs
他の路線について：尻を上流へアドバタイズしません。
This approach is flexible and scales well as it gives control to the party with the special needs, distributes the workload and avoids the coordination overhead required by proxy aggregation.
このアプローチは、柔軟であり、それは特別なニーズを持つパーティーに制御することができますよううまくスケール、作業負荷を分散し、プロキシ凝集して必要な調整のオーバーヘッドを回避できます。
A provider shall aggregate all the routes it originates, as documented in Section 3. The only difference is that the provider may be providing full routes to certain BGP customers where no outbound filtering is presently in place. Experience has shown that inconsistent route announcement (e.g., aggregate at the interconnects but not toward certain customers) can cause serious routing problems for the Internet as a whole because of longest-match routing. In certain cases announcing the more-specifics to customers might provide for more accurate IGP metrics and could be useful for better load-balancing. However, the potential risk seems to outweigh the benefit, especially given the increasing complexity of connectivity that a customer may have. As a result, every effort shall be made to ensure consistent route aggregation for all BGP peers. This means deploying filters for the BGP peers which receive full routes.
プロバイダは、唯一の違いは、プロバイダがないアウトバウンドフィルタリングが適所に現在されていない特定のBGP顧客に完全なルートを提供することができることである項3に記載のように、それは、発信するすべてのルートを集約しなければなりません。経験は一貫性のないルート告知（相互接続ではなく、特定の顧客に向けて、例えば、集計が）ので、最長一致ルーティングの全体としてのインターネットのための重大なルーティングの問題を引き起こす可能性があることを示しています。お客様に、より-詳細を発表する特定の場合には、より正確なIGPメトリックを提供する可能性があり、より良い負荷分散のために有用である可能性があります。しかし、潜在的なリスクは、特に顧客が持っているかもしれ接続の複雑化を考えると、利益を上回るようです。その結果、あらゆる努力は、すべてのBGPピアのための一貫性のあるルート集約を確保するために行わなければなりません。これは、完全なルートを受け取るBGPピアのためのフィルタを配備することを意味します。
In summary, the aggregation strategy for a provider shall be:
要約すると、プロバイダの集約戦略はしなければなりません。
- In announcing customer routes:
- 顧客のルートを発表するには：
For routes originated by itself/dedicated-AS/private-AS:
tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics
For routes originated by other customer ASs: advertise
他の顧客のASから発信ルートの場合：広告を掲載
For any other routes: do not advertise
他のルートの場合：アドバタイズしません。
- In announcing full routes:
- 完全なルートを発表して：
For routes originated by itself/dedicated-AS/private-AS:
tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics
For any other routes: advertise
他のルートの場合：広告を掲載
Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, and AS 2000 is a customer of AS 1000 with a "portable address" 160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000. Assume that 208.128.0.0/19 does not need to be propagated beyond AS 1000.
1000二つの大きな凝集208.128.0.0/12と166.55.0.0/16と「ティア1」のプロバイダであり、そして2000など「携帯アドレス」160.75と同様に1000の顧客である。図3に示されている例を考えます。 0.0 / 16と1000 ASから割り当てられたアドレス208.128.0.0/19 208.128.0.0/19が1000を超えて伝播する必要がないと仮定します。
+----------------+
| AS 1000 |
| 208.128.0.0/12 |
| 166.55.0.0/16 |
+----------------+
|
| BGP
|
|
+----------------+
| AS 2000 |
| 208.128.0.0/19 |
| 160.75.0.0/16 |
+----------------+
Figure 3
図3
Then, based on the framework presented, AS 1000 would
次に、フレームワークに基づいて1000と、提示だろう
- originate and advertise the BGP routes 208.128.0.0/12 and 166.55.0.0/16, and suppress more-specifics originated by itself/private-ASs/dedicated-ASs
- 発信およびBGPルート208.128.0.0/12と166.55.0.0/16を宣伝し、専用-のAS /プライベート-のAS /自身が発信し、より-仕様を抑制
- advertise the routes received from the customer AS 2000
- 2000年、顧客から受け取ったルートをアドバタイズ
and AS 2000 would
そして2000などでしょう
- originate BGP route 208.128.0.0/19 and 160.75.0.0/16
- BGPルート208.128.0.0/19と160.75.0.0/16を発信
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS 1000 and suppress the more specifics originated by itself/private-AS/dedicated-AS, tagging the route 208.128.0.0/19 with "no-export"
- 1000とそのプロバイダに160.75.0.0/16 208.128.0.0/19との両方を宣伝し、「ノー輸出」でルート208.128.0.0/19をタグ付け自体/プライベート-AS /専用-AS、によって発信より多くの詳細を抑制
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP customers (if any) and suppress the more-specifics originated by itself/private-AS/dedicated-AS, plus any other routes the customers may desire to receive
- （もしあれば）そのBGP顧客に160.75.0.0/16 208.128.0.0/19との両方を宣伝し、民間-AS /専用-AS自体によって発信より-仕様/、プラス顧客が受信しようとする任意の他のルートを抑制
The sample configuration which implement these policies (in Cisco syntax) is given in Appendix A.
（シスコの構文で）これらのポリシーを実装するサンプル設定は、付録Aに記載されています
The authors would like to thank Roy Alcala of MCI for a number of interesting hallway discussions related to this work. The IETF's IDR Working Group also provided many helpful comments and suggestions.
作者はこの作品に関連した興味深い廊下の議論の数のMCIのロイアルカラに感謝したいと思います。 IETFのIDR作業部会はまた、多くの有益なコメントや提案を提供しました。
[1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[1] Rekhter、Y.とT.李、RFC 1518 "CIDRとのIPアドレス割り当てのためのアーキテクチャ" を、1993年9月。
[2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[2]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[3] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[4] Rekhter, Y. and P., Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[4] Rekhter、Y.、およびP.、グロス、 "インターネットでのボーダゲイトウェイプロトコルの応用"、RFC 1772、1995年3月。
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[5] Rekhter、Y.、 "マルチプロバイダのインターネットでのルーティング"、RFC 1787、1995年4月。
[6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[6]チャンドラ、R.、Trainaの、P.およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[7] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996.
[7]チェン、E.とT.ベイツ、「マルチホームルーティングでのBGPコミュニティ属性の応用」、RFC 1998、1996年8月。
[8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[8]ファーガソン、P.とH.バーコウィッツは、「ネットワークのリナンバリングの概要は：なぜ私はそれをしたいだろうし、それはとにかく何ですか？」、RFC 2071、1997年1月。
[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[9]バーコウィッツ、H.、 "ルータリナンバリングガイド"、RFC 2072、1997年1月。
[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a Dedicated AS for Sites Homed to a Single Provider", RFC 2270, January 1998.
[10]スチュワート、J.、ベイツ、T.、チャンドラ、R.、およびチェン、E.、1998年1月、RFC 2270 "シングルプロバイダをホームサイトのような専用の使用" を参照してください。
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[11]カーペンター、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[12]大工、B.およびY. Rekhter、 "リナンバリングは作業が必要"、RFC 1900、1996年2月。
[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Configuration Guide (Addendum), May 1995.
[13]シスコシステム、Cisco IOSソフトウェアバージョン10.3ルータ製品のコンフィギュレーション・ガイド（補遺）、1995年5月。
Enke Chen Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
エンケ陳シスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134-1706
Phone: +1 408 527 4652 EMail: enkechen@cisco.com
電話：+1 408 527 4652 Eメール：enkechen@cisco.com
John W. Stewart, III Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043
ジョン・W・スチュワート、IIIジュニパーネットワークス株式会社385 Ravendaleドライブマウンテンビュー、CA 94043
Phone: +1 650 526 8000 EMail: jstewart@juniper.net
電話：+1 650 526 8000 Eメール：jstewart@juniper.net
A. : Example Cisco Configuration
A.：例Ciscoコンフィギュレーション
This appendix lists the Cisco configurations for AS 2000 of the examples presented in Section 5. The configuration here uses the AS-path for outbound filtering although it can also be based on BGP community. Several route-maps are defined that can be used for peering with the upstream provider, and for peering with customers (announcing full routes or customer routes).
この付録では、それはまた、BGPコミュニティに基づいて行うことができるが、設定はここアウトバウンドフィルタリングのためのASパスを使用して、セクション5に示す例の2000などのために、シスコの構成を示します。いくつかのルートマップは、上流プロバイダとのピアリングのために使用することができるように定義し、顧客とのピアリングのために（フルルートや顧客ルートを発表）されています。
!!# inject aggregates ip route 160.75.0.0 255.255.0.0 Null0 254 ip route 208.128.0.0 255.255.224.0 Null0 254 ! router bgp 2000 network 160.75.0.0 mask 255.255.0.0 network 208.128.0.0 mask 255.255.224.0 neighbor x.x.x.x remote-as 1000 neighbor x.x.x.x route-map export-routes-to-provider out neighbor x.x.x.x send-community ! !!# match all ip as-path access-list 1 permit .* ! !!# List of internal AS and private ASs that are safe to aggregate ip as-path access-list 10 permit ^$ ip as-path access-list 10 permit ^64999_ ip as-path access-list 10 deny .* ! !!# list of other customer ASs ip as-path access-list 20 permit ^3000_
!!＃集約IPルート160.75.0.0 255.255.0.0ヌル0 254 IPルート208.128.0.0 255.255.224.0ヌル0 254を注入！ルータのBGP 2000ネットワーク160.75.0.0マスク255.255.0.0ネットワーク208.128.0.0マスク255.255.224.0隣接x.x.x.x千リモート-として隣人x.x.x.xルートマップのエクスポート・ルート・ツー・プロバイダ送り出す-コミュニティをx.x.x.x隣人！ !!＃。すべてのIP ASパスアクセスリスト1許可と一致します*！ !!＃の内部ASのリストとプライベートのAS IPを集約しても安全なようにパスアクセスリスト10の許可^ $ IPとしてパスアクセスリスト10の許可^ 64999_ IPなどのパスアクセスリスト10は拒否。*！ !!他の顧客のASのIPの＃リストASパスアクセスリスト20の許可^ 3000_
!!# List of prefixes to be tagged with "no-export" access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 !!# Filter out the more specifics of large aggregates, and permit the rest access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255 access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255 access-list 102 permit ip any any !
!!「ノー輸出」でタグ付けされるプレフィックスの＃一覧アクセスリスト101許可のIP 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 !!大きな凝集体のより具体的アウト＃フィルターは、残りのアクセスを許可102許可IP 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0アクセスリスト-list 102拒否IP 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255アクセスリスト102許可のIP 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0アクセスリスト102は、拒否のIP 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255アクセスリストは102許可は、任意の任意のIP！
!!# route-map with the upstream provider route-map export-routes-to-provider permit 10 match ip address 101 set community no-export route-map export-routes-to-provider permit 20 match as-path 10 match ip address 102 route-map export-routes-to-provider permit 30 match as-path 20 ! !!# route-map with BGP customers that desire only customer routes route-map export-customer-routes permit 10 match as-path 10 match ip address 102 route-map export-customer-routes permit 20 match as-path 20 ! !!# route-map with BGP customers that desire full routes route-map export-full-routes permit 10 match as-path 10 match ip address 102 route-map export-full-routes permit 20 match as-path 1 !
!!上流プロバイダルートマップ輸出ルート・ツー・プロバイダ許可10試合のIPアドレス101セットコミュニティなし輸出ルートマップ輸出ルート・ツー・プロバイダ許可20一致ASパス10マッチ付きIP＃ルートマップ102ルートマップを扱う輸出ルート・ツー・プロバイダ許可証30試合のように、パス20！ !!ルートマップのエクスポート - 顧客ルートは10試合のように、パス10試合のIPアドレス102ルートマップのエクスポート - 顧客ルートは20試合を許可する許可のみ顧客ルートを望むBGP顧客と＃ルートマップとしてパス20！ !!フルルートのルートマップのエクスポート - フルルートは10試合のIPアドレス102ルートマップのエクスポート - フルルートが20試合を許可するよう、パス10試合を許可望むBGP顧客と＃ルートマップとしてパス1！
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。