この文書はRFC1998の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group E. Chen
Request for Comments: 1998 MCI
Category: Informational T. Bates
cisco Systems
August 1996
An Application of the BGP Community Attribute
in Multi-home Routing
マルチホームルーティングでの
ＢＧＰコミュニティ属性の応用
Status of This 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.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document presents an application of the BGP community attribute
[2] in simplifying the implementation and configuration of routing
policies in the multi-provider Internet. It shows how the community
based configuration can be used to replace the AS-based customization
of the BGP "LOCAL_PREF" attribute, a common method used today. Not
only does the technique presented simplifies configuration and
management at the provider level, it also represents a paradigm shift
in that it gives the potential for the customer to control its own
routing policy with respect to its service provider, as well as
providing the ability for policy configuration to be done at a prefix
based granularity rather than the more common AS based granularity.
この文書はマルチプロバイダのインターネットでルーティングポリシの実装
と設定を単純化するためのＢＧＰコミュニティ属性[2]の応用を提示します。
これはどのようにコミュニティに基づく設定が、今日一般的なＢＧＰ「ロー
カル優先」属性のＡＳに基づくのカスタマイズの置換えに使うことができる
かを示します。このテクニックはプロバイダレベルの設定と管理を単純化す
るだけではなく、顧客がそのサービスプロバイダに関して自分自身のルーティ
ングポリシを制御する可能性を与え、一般的なＡＳの基づく精度よりプレ
フィックス基づく精度のポリシ設定の能力を供給する点で、同じくパラダイ
ムの転換を意味します。
1. Introduction
1. はじめに
In the multi-provider Internet, it is common for a service subscriber
(i.e., customer) to have more than one service provider, or to have
arrangements for redundant connectivity to the global connected
Internet. As discussed in [3], routing strategies in these cases
usually require coordination between the service subscriber and its
providers, which typically leads to customization of router
configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber,
but also by its providers. Due to the large number of customers a
provider serves, customization of router configurations at the
provider level may present management and scalability problems.
マルチプロバイダのインターネットで、サービス加入者（すなわち、顧客）
にとって、１つ以上のサービスプロバイダを持ことや、グローバル接続イン
ターネットに冗長な接続性を持つことはサービス加入者にとって一般的です。
[3]で論じられるように、これらの場合のルーティング戦略は、通常サービ
ス加入者とそのプロバイダの間の調整を必要とし、そしてそれは加入者だけ
ではなく、一般にそのプロバイダにもルータ設定（例えば、ＢＧＰ「ローカ
ル優先」）のカスタム化に導きます。プロバイダがサポートする顧客数が多
いため、プロバイダレベルにおいてのルータ設定のカスタム化は管理のスケー
ラビリティ問題を導入するかもしれません。
This document presents an application of the BGP community attribute
in simplifying the implementation of routing strategies in the
multi-provider Internet. More specifically, the technique presented
uses a community-based, rather than the common AS-based,
configuration of the BGP "LOCAL_PREF". It essentially removes the
need for customized configuration of the BGP "LOCAL_PREF" attribute
at the provider level while maintaining the same level of routing
functionality and flexibility.
この文書はマルチプロバイダのインターネットでのルーティング戦略の実装
を単純化するため、ＢＧＰコミュニティ属性の応用を提示します。特に、使
用したテクニックは、一般的なＡＳに毎のＢＧＰ「ローカル優先」ではなく、
コミュニティに基づく設定を使います。これは、ルーティング機能と柔軟性
の同じレベルを維持したまま、プロバイダレベルにおいて本質的にＢＧＰ
「ローカル優先」属性のカスタマイズされた設定の必要性を取り除きます。
It also represents a paradigm shift in that it gives the potential
for the customer to control its own routing policy with respect to
its service provider, as well as providing the ability for policy
configuration to be done at a prefix based granularity rather than
the more common AS based granularity in use today.
これは顧客がそのサービスプロバイダに関して自分自身のルーティングポリ
シを制御する可能性を与え、現在の一般的なＡＳの基づく精度より、プレ
フィックス基づく精度のポリシ設定の能力を供給する点で、同じくパラダイ
ムの転換を意味します。
2. AS-based Configuration and its Drawbacks
2. ＡＳベースの設定とその欠点
As discussed in [3], in today's multi-provider Internet, customized
configuration of the BGP "LOCAL_PREF" attribute is often required to
implement common routing strategies such as load-sharing or backup.
There are two main reasons:
[3]で論じられるように、今日のマルチプロバイダのインターネットで、ＢＧ
Ｐ「ローカル優先」属性のカスタマイズされた設定がしばしば負荷分散ある
いはバックアップのような一般的ルーティング戦略を実行するように要求さ
れます。２つの主な理由があります：
o Lack of available implementations and deployment of routing
software that supports the "Destination Preference Attribute"
(DPA) as specified in [4].
o [4]で指定される「宛先優先属性」（ＤＰＡ）をサポートする利用可能な
ルーティングソフトウェアの実装と配置の欠如。
DPA allows one to specify a globally transitive preference so
that return traffic favors certain path. As discussed in [3],
the attribute will be very useful in influencing route selection
for routes with identical "LOCAL_PREF" and equal AS-path length.
ＤＰＡは帰りのトラフィックがある特定の経路を優先するように、グロー
バル規模で中継の優先を指定することを許します。[3]で論じられるよう
に、属性は等しい「ローカル優先」と等しいＡＳパス長の経路で、経路
選択に影響を与える事に役立ちます。
o In the multi-provider Internet, it is common for a provider
to assign higher BGP "LOCAL_PREF" values for routes from its
customers than from other service providers. This practice
provides some degree of protection for its customer routes,
and it facilitates implementation of certain routing
strategies. It, however, also complicates other routing
implementations such as backup arrangement, thus, requiring
customized "LOCAL_PREF" configuration.
o マルチプロバイダのインターネットで、プロバイダが顧客からの経路に
他のサービスプロバイダからより高いＢＧＰ「ローカル優先」値を割り
当てることは一般的です。この実行はその顧客ルートにある程度の保護
を提供します、そしてある特定のルーティング戦略の実行を容易にしま
す。それは、しかしながら、同じくバックアップ配置のような他のルー
ティング実行を複雑にし、それで、カスタマイズされた「ローカル優先」
設定を必要とします。
Figure 1 shows a typical case of a backup arrangement in the multi-
provider Internet. In Figure 1, AS1 and AS2 are both providers, and
AS3 and AS4 are customers of AS1 and AS2, respectively. AS3 has
entered a bilateral agreement with AS4 to provide backup to each
other. That is, AS3 would use its direct link to AS4 to reach only
AS4 in the normal circumstance, and for transit in the case of a
failure between AS3 and AS1. To realize this routing agreement, AS3
requests that its provider AS1 adjust its BGP "LOCAL_PREF"
configuration so that AS1 reaches AS4 via AS2.
図１がマルチプロバイダのインターネットでのバックアップの取り決めの典
型的な場合を示します。図１で、ＡＳ１とＡＳ２は両方ともプロバイダです、
そしてＡＳ３とＡＳ４はそれぞれＡＳ１とＡＳ２の顧客です。ＡＳ３がＡＳ
４とお互いにバックアップを供給する２者協定をはじめました。すなわち、
ＡＳ３がＡＳ４への直接リンクを使用し、通常はＡＳ４に達するためだけに
使用し、ＡＳ３とＡＳ１に障害が発生した場合に中継に使用します。このルー
ティング協定を理解するために、ＡＳ３がプロバイダＡＳ１に、ＡＳ２経由
でＡＳ４に到達するように、そのＢＧＰ「ローカル優先」設定を調整するこ
とを要請します。
+------+ +------+
| AS1 |------| AS2 |
+------+ +------+
| |
+------+ +------+
| AS3 |------| AS4 |
+------+ +------+
Figure 1: Typical Backup Scenario
図１：典型的バックアップシナリオ
Primarily due to scalability and management concerns, most providers
only perform "LOCAL_PREF" customization based on ASs, not on IP
prefixes. If IP prefix-based "LOCAL_PREF" configuration is needed, a
technique known as as the BGP AS-path manipulation can be used.
However, it is currently only available in certain vendor's products.
主にスケーラビリティと管理の懸念のために、たいていのプロバイダが、Ｉ
Ｐプレフィックスではなく、ＡＳに基づいて「ローカル優先」カスタム化を
行うだけです。もしＩＰプレフィックスベースの「ローカル優先」設定が必
要とされるなら、ＢＧＰ ＡＳパス操作として知られるテクニックが使えま
す。しかしながら、現在それはある特定のベンダの製品でだけ利用可能です。
There are several drawbacks with the the practice of AS-based BGP
"LOCAL_PREF" configuration at the provider level:
プロバイダレベルにおいて、ＡＳベースのＢＧＰ「ローカル優先」設定の実
行にはいくつかの欠点があります：
o The implementation tends to less efficient due to the process
of coordination and configuration. More importantly, the
process needs to be repeated each time a change (e.g., adding
a new AS) occurs.
o 実装は調整と設定の処理のためにより効率が低くなる傾向があります。
より重要なことに、処理は変更（例えば、新しいＡＳの追加）が生じる
毎に繰り返されます。
o The AS-based customization complicates router configuration
and increases complexity of network operation. It has become
a serious scalability issue for providers.
o ＡＳベースのカスタム化はルータ設定を複雑にして、そしてネットワー
クオペレーションの複雑さを増やします。これはプロバイダにとっての
大きなスケーラビリティ問題になりました。
o It can not implement prefix-based configuration without the
AS-path manipulation (i.e., using fake AS).
o これはＡＳパス操作（すなわち、偽ＡＳ使用）なしにプレフィックスベー
スの設定を実行することができません。
o Keeping configuration up-to-date is some times problematic.
o 設定を最新にしておくことは、ある場合に問題が多いです。
3. How the BGP Community Attribute Can Help
3. ＢＧＰコミュニティ属性が助けになる方法
3.1 Overview of the Community Attribute
3.1 コミュニティ属性の概観
The BGP community path attribute is an optional transitive attribute
of variable length [1,2]. The attribute consists of a set of four
octet values, each of which specify a community. The community
attribute values are encoded using an AS number in the first two
octets, with the remaining two octets defined by the AS. As defined
in [2], a community is a group of destinations (i.e. prefixes) that
share some common attribute. Each destination can belong to multiple
communities. All prefixes with the community attribute belong to the
communities listed in the attribute.
ＢＧＰコミュニティパス属性は可変長の任意の通過属性です[1,2]。属性はそ
れぞれがコミュニティを指定する４オクテット価の集合から成り立ちます。
コミュニティ属性値は最初の２オクテットがＡＳ番号で、残りの２オクテッ
トはＡＳで定義されます。[2]で定義されるように、コミュニティは宛先（つ
まりプレフィックス）のグループで、グループはある属性を共有します。そ
れぞれの宛先は多数のコミュニティに属することができます。すべてのコミュ
ニティ属性を持つプレフィックスは属性でリストアップされたコミュニティ
に属します。
The BGP community allows one to group a set of prefixes and perform
routing decisions based on the identity of the group.
ＢＧＰコミュニティはプレフィックスをグループにまとめて、グループの識
別子に基づいたルーティング決定を行うことを許します。
The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE
(0xFFFFFF02) are intuitive, and can be used for optimizing routing
and for improving route aggregation.
既知コミュニティNO_EXPORT(0xFFFFFF01)とNO_ADVERTISE (0xFFFFFF02)は直
観的であって、そしてルーティング最適化や経路集約の改善に対して使うこ
とができます。
3.2 Community-based Configuration
3.2 コミュニティベース設定
With the BGP community attribute [2], a provider can now use
community-based, rather than AS-based, configuration of BGP
"LOCAL_PREF". The provider first needs to coordinate with its
customers a set of communities to be mapped to certain BGP
"LOCAL_PREF" values. The provider can then apply a uniform BGP
configuration to all its customers that would capture routes with the
community values, and set up the appropriate BGP "LOCAL_PREF" values
accordingly. A customer that requires customization in its provider
BGP "LOCAL_PREF" configuration can simply send the appropriate
community values in its routing announcements.
ＢＧＰコミュニティ属性[2]によって、プロバイダが今ＡＳベースではなくコ
ミュニティベースのＢＧＰ「ローカル優先」設定を使うことができます。プ
ロバイダは最初にある特定のＢＧＰ「ローカル優先」値にマップされるコミュ
ニティのセットをその顧客と調整する必要があります。プロバイダはそれか
ら同一のＢＧＰ設定をコミュニティ値を経路を取り込むすべての顧客に適用
でき、そして相応に適切なＢＧＰ「ローカル優先」値を設定するでしょう。
そのプロバイダのＢＧＰ「ローカル優先」設定のカスタマイゼーションを必
要とする顧客は、適切な共同体値をそのルーティング広告に送ることができ
ます。
The major advantages of using this technique include:
このテクニックを使うことについての主な利点は下記の通りです：
o The customer has full control in the process, which makes a
lot of sense as the customer is in a position to have better
understanding about its own topology and routing policy
requirement.
o 顧客は処理の完全な制御を持ち、そしてこれｒは、顧客が自分自身のト
ポロジとルーティングポリシー条件についてもっと良い理解を持つ立場
にあるから、重要な意味を持ちます。
o The effect of route-based customization in BGP "LOCAL_PREF"
configuration by providers can now be achieved, thus, removing
the need of AS-Path manipulation in certain cases.
o プロバイダによるＢＧＰ「ローカル優先」設定での経路ベースのカスタ
ム化の効果は、今、ある特定の場合にＡＳパスの扱いの必要性を取り除
いて、成し遂げることができます。
o It addresses the scalability issue facing providers as it
distributes the configuration work to the customer that
requires customization.
o これはカスタマイゼーションを必要とする顧客に設定をする時のプロバ
イダが直面するスケーラブル問題を扱います。
4. A Real-World Implementation Example
4. 実世界での実行例
MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute value
as part of its routing policy configuration process. Different BGP
"LOCAL_PREF" values are assigned for routes from different sources.
Table 1 details these values:
ＭＣＩはそのルーティングポリシ設定プロセスの一部として現在ＢＧＰ「ロー
カル優先」属性値の激しい使用をします。異なったＢＧＰ「ローカル優先」
値が異なったソースからの経路のために割り当てられます。表１がこれらの
値を詳述します：
+-------------------------+------------+
| Category | LOCAL_PREF |
+-------------------------+------------+
|Customer Routes | 100 |
|Customer backup Routes | 90 |
|Other ISP Routes | 80 |
|Customer-Provided backup | 70 |
+-------------------------+------------+
Table 1: Defined LOCAL_PREF Values
表１：定義されたローカル優先値
Note:
ノート：
o The value '100' is the default value used within our network
configuration.
o 価値「１００」は我々のネットワーク設定で使われるデフォルト値で
す。
o In most cases, the MED attribute set by a customer is
sufficient for customer backup routes (e.g., T1 backs up T3).
However, in certain cases configuration of "LOCAL_PREF" will
still be necessary until the BGP DPA attribute is available.
o たいていの場合に、顧客の設定したＭＥＤ属性は顧客のバックアップ
経路に（例えば、Ｔ１がＴ３のバックアップをとる）に十分です。し
かしながら、ある特定の場合に「ローカル優先」の設定は、ＢＧＰの
ＤＰＡ属性が利用可能になるまで、必要であるでしょう。
To make use of the BGP community attribute, several community values
(MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
by customers to tag routes so that the appropriate "LOCAL_PREF"
values are configured. Table 2 lists the appropriate community
attribute values (and the mappings of community to LOCAL_PREF):
ＢＧＰコミュニティ属性を利用するために、適切な「ローカル優先」値が配
置されるように、タグルートに顧客が使うことができるいくつかのコミュニ
ティ値（ＭＣＩのＡＳ番号：３５６１ ＝ ０x０DE９ ）が定義されました。
表２で適切なコミュニティ属性値（とコミュニティからローカル優先への対
応）をリストアップします：
+---------------------+------------+
| community | LOCAL_PREF |
+---------------------+------------+
|3561:70 (0x0DE90046) | 70 |
|3561:80 (0x0DE90050) | 80 |
|3561:90 (0x0DE9005A) | 90 |
+---------------------+------------+
Table 2: Community to LOCAL_PREF Mapping
表２：コミュニティからローカル優先への対応
A customer requiring MCI to configure BGP "LOCAL_PREF" values other
than the default can tag their routes with the defined communities.
The community values can be configured either based on an AS path
list or an IP address access list. A cisco systems software specific
configuration example is given in Appendix A to show how this can be
achieved.
ＭＣＩにデフォルト以外のＢＧＰ「ローカル優先」値を設定するように要求
している顧客が、定義されたコミュニティで経路にタグを付けることができ
ます。コミュニティ値はＡＳパスリストあるいはＩＰアドレスアクセスリス
トに基づいて設定できます。どのようにこれが成し遂げられることができる
か示すために、ＣＩＳＣＯシステムソフトウェア固有の設定例を付録Ａで示
します。
A uniform BGP configuration (see Appendix B, again cisco systems
software specific) is applied by MCI to peers with customers that
configure the appropriate "LOCAL_PREF" values based on the
communities received.
受信したコミュニティベースの適切な「ローカル優先」値の設定をする顧客
のピアに、ＭＣＩによって一様ＢＧＰ設定が適用されます（付録Ｂを見て下
さい、ＣＩＳＣＯシステムソフトウェア固有です）。
This technique has been tested and is in use with several customers,
and the response has been very positive. We are in the process of
migrating all other customized BGP "LOCAL_PREF" configurations to
this uniform community based configuration approach.
このテクニックはテストされた、そして数人の顧客と共に使用中で、そして
結果は肯定的でした。我々はこの同一のコミュニティに基づく設定方法以外
のカスタマイズされたＢＧＰ「ローカル優先」設定を移行中です。
5. References
5. 参考文献
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[2] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[3] Chen, E., and T. Bates, "Current Practice of Implementing
Symmetric Routing and Load Sharing in the Multi-Provider
Internet", Work in Progress.
[4] Chen, E., and T. Bates, "Destination Preference Attribute for
BGP", Work in Progress.
[5] Chen, E., and T. Bates, "Application of the BGP Destination
Preference Attribute in Implementing Symmetric Routing",
Work in Progress.
[6] cisco systems, cisco IOS Software Version 10.3 Router Products
Configuration Guide (Addendum), May 1995.
6. Security Considerations
6. セキュリティの考察
Security issues are not discussed in this memo.
セキュリティ問題がこのメモで論じられません。
7. Acknowledgments
7. 謝辞
The authors would specifically like to thank Ravi Chandra, Tony Li
and Paul Traina of cisco systems for devising and implementing the
community attribute.
著者は特にコミュニティ属性を考案し実装したことに対してＣＩＳＣＯシス
テムのRavi ChandraとTony LiとPaul Trainaに感謝します。
8. Authors' Addresses
8. 著者のアドレス
Enke Chen
MCI
2100 Reston Parkway
Reston, VA 22091
Phone: +1 703 715 7087
EMail: enke@mci.net
Tony Bates
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 527 2470
EMail: tbates@cisco.com
Appendix
付録
These appendices list cisco systems software specific configuration
examples for configuring communities, and for uniform route-map
definition that sets up the appropriate "LOCAL_PREF" values based on
the corresponding community values. These examples are given purely
to show a working example of how the desired effect discussed in this
document can be achieved. Please refer to [6] for more specific
information on cisco configuration and syntax.
これらの付録は、コミュニティの設定と、対応するコミュニティ値に基づい
て適切な「ローカル優先」値を設定するルートマップ定義のために、ＣＩＳ
ＣＯシステムソフトウェア特有設定例をリストアップします。これらの例は
この文書で論じられた望ましい効果を成し遂げられることができる方法の実
用的な例を示すためだけに与えられます。どうかＣＩＳＣＯ設定と構文につ
いてのより特定の情報のために[6]を参照してください。
Appendix A. Community Configuration
付録Ａ．コミュニティ設定
The community values can be configured either based upon an AS path
list or based an IP address access list. Here is an example that
includes both cases:
コミュニティ値はＡＳパスリストに基づいてか、ＩＰアクセスリストに基づ
いて設定できます。ここに両方の場合を含む例があります：。
!!
router bgp xxxx
neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20 out
neighbor x.x.x.x route-map config-community out
neighbor x.x.x.x send-community
!
!!# match all
ip as-path access-list 1 permit .*
!
!!# list of customer ASs
ip as-path access-list 20 permit ^$
ip as-path access-list 20 permit ^64700_
ip as-path access-list 20 deny .*
!
!!# AS path based matching, backup for another ISPs customer
ip as-path access-list 40 permit _64710_
ip as-path access-list 40 permit _64711_
ip as-path access-list 40 deny .*
!
!!# route-map
route-map config-community permit 10
match as-path 40
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!
Note: The community can also be configured based on IP prefixes
instead of AS numbers. For example,
ノート：コミュニティはＡＳ番号の代わりにＩＰプレフィックスに基づいて
配置されることができます。例えば、
!
access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0
!
route-map config-community permit 10
match ip address 101
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!
Appendix B. Uniform Route-map Configuration
付録Ｂ．一様ルートマップ設定
Here is the uniform route-map that can be used for all BGP
customers:
ここにすべてのＢＧＰ顧客に使うことができる同一のルートマップがありま
す：
!!# routes primary via another ISP
ip community-list 70 permit 0x0DE90046
ip community-list 70 deny
!
!!# routes also homed to another ISP, but with DPA or
!!# AS-path length as the tie-breaker
ip community-list 80 permit 0x0DE90050
ip community-list 80 deny
!
!!# customer backup routes
ip community-list 90 permit 0x0DE9005A
ip community-list 90 deny
!
!!# the route-map applied to BGP customers
route-map set-customer-local-pref permit 10
match community 70
set local-preference 70
route-map set-customer-local-pref permit 20
match community 80
set local-preference 80
route-map set-customer-local-pref permit 30
match community 90
set local-preference 90
route-map set-customer-local-pref permit 40
match as-path 1
set local-preference 100
!