[要約] RFC 10005は、BGPマルチパスで帯域幅に応じた重み付き負荷分散を行うため、リンク帯域幅を伝える拡張コミュニティの形式と処理規則を規定します。生成、受信、ネクストホップ変更の有無に応じた再広告、複数値の演算、エラー処理と段階的導入時の考慮事項を定義します。
Internet Engineering Task Force (IETF) P. Mohapatra
Request for Comments: 10005 Google LLC
Category: Standards Track R. Das, Ed.
ISSN: 2070-1721 HPE
S. Mohanty, Ed.
Zscaler
S. Krier
Cisco Systems
R.J. Szarecki
Google LLC
A. Gattani
Arista Networks
June 2026
This document defines a BGP extended community, the Link Bandwidth Extended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type.
この文書では、BGP 拡張コミュニティであるリンク帯域幅拡張コミュニティを定義します。これは、マルチパス シナリオで重み付けされた負荷分散を可能にする帯域幅情報を伝送します。この拡張コミュニティ タイプの形式と処理ルールを指定します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10005.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10005 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Link Bandwidth Extended Community
3. Protocol Procedures
3.1. Sender (Originating Link Bandwidth Extended Community)
3.2. Receiver (Receiving Link Bandwidth Extended Community)
3.3. Re-Advertisement Procedures
3.3.1. Re-Advertisement with Next Hop Change
3.3.2. Re-Advertisement with Next Hop Unchanged
3.4. Link Bandwidth Extended Community Arithmetic and BGP
Multipath
4. Error Handling
5. IANA Considerations
6. Security Considerations
7. Operational Considerations
7.1. Inconsistent Deployment
7.2. Bandwidth Value
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Document History
Acknowledgments
Contributors
Authors' Addresses
Load-balancing is a critical aspect of network design, enabling efficient utilization of available bandwidth and improving overall network performance. Traditional equal load-balancing does not account for the varying capacities of different paths. This document suggests that the bandwidth be carried in the network using one of two new extended communities [RFC4360]: the transitive and non-transitive Link Bandwidth Extended Community. The Link Bandwidth Extended Community carries the bandwidth information of a directly connected link or multi-hop/multipath next hop as advertised by a router. This mechanism facilitates maximizing utilization of network resources.
負荷分散はネットワーク設計の重要な側面であり、利用可能な帯域幅の効率的な利用を可能にし、ネットワーク全体のパフォーマンスを向上させます。従来の均等なロード バランシングでは、パスごとに異なる容量が考慮されていません。この文書は、2 つの新しい拡張コミュニティ [RFC4360] の 1 つである推移的リンク帯域幅拡張コミュニティと非推移的リンク帯域幅拡張コミュニティの 1 つを使用して、ネットワーク内で帯域幅を伝送することを提案しています。リンク帯域幅拡張コミュニティは、ルーターによってアドバタイズされた、直接接続されたリンクまたはマルチホップ/マルチパス ネクスト ホップの帯域幅情報を伝送します。このメカニズムにより、ネットワーク リソースの最大限の利用が促進されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The Link Bandwidth Extended Community is defined as a BGP extended community that carries the bandwidth information of a router (represented by BGP next hop) that is connecting to a remote network. This community can be used to inform other routers about the available bandwidth through a given route.
リンク帯域幅拡張コミュニティは、リモート ネットワークに接続しているルーター (BGP ネクスト ホップで表される) の帯域幅情報を伝送する BGP 拡張コミュニティとして定義されます。このコミュニティを使用すると、特定のルートを通じて利用可能な帯域幅について他のルーターに通知できます。
The Link Bandwidth Extended Community can be either transitive or non-transitive. Therefore, the value of the high-order octet of the extended Type field can be 0x00 or 0x40, respectively. The value of the low-order octet of the extended Type field for this community is 0x04.
リンク帯域幅拡張コミュニティは、推移的または非推移的のいずれかになります。したがって、拡張 Type フィールドの上位オクテットの値は、それぞれ 0x00 または 0x40 になります。このコミュニティの拡張 Type フィールドの下位オクテットの値は 0x04 です。
The Global Administrator sub-field in the Value field SHOULD be set to the Autonomous System Number (ASN) of the router attaching the Link Bandwidth Extended Community, but it MAY contain any 2-octet value. If the ASN cannot be represented in 2 octets, AS_TRANS [RFC6793] SHOULD be used in the Global Administrator sub-field. The encoding of the full 4-octet ASNs is not supported by the Link Bandwidth Extended Community. Such a capability, should the operational need for it arise, may be provided by a new BGP extension. The value in the Global Administrator sub-field does not affect the use or semantics of the Link Bandwidth Extended Community. This approach maintains consistency with 2-octet community registries and remains operationally familiar.
「値」フィールドの「グローバル管理者」サブフィールドは、リンク帯域幅拡張コミュニティを接続するルーターの自律システム番号 (ASN) に設定されるべきです (SHOULD)。ただし、任意の 2 オクテット値を含めてもよい (MAY)。If the ASN cannot be represented in 2 octets, AS_TRANS [RFC6793] SHOULD be used in the Global Administrator sub-field.The encoding of the full 4-octet ASNs is not supported by the Link Bandwidth Extended Community.Such a capability, should the operational need for it arise, may be provided by a new BGP extension.The value in the Global Administrator sub-field does not affect the use or semantics of the Link Bandwidth Extended Community.This approach maintains consistency with 2-octet community registries and remains operationally familiar.
The bandwidth value is expressed as 4 octets in the floating point format of [IEEE.754-2019], with units being bytes (not bits!) per second. It is carried in the Local Administrator sub-field of the Value field.
帯域幅の値は、[IEEE.754-2019] の浮動小数点形式で 4 オクテットとして表され、単位は 1 秒あたりのバイト (ビットではありません!) です。これは、「値」フィールドの「ローカル管理者」サブフィールドに格納されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=0x00/0x40 | SubType=0x04 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Link Bandwidth Extended Community
図 1: リンク帯域幅拡張コミュニティ
Type:
タイプ：
A 1-octet field that MUST be set to 0x00 or 0x40 to indicate transitive/non-transitive.
推移的/非推移的を示すために 0x00 または 0x40 に設定しなければならない 1 オクテットのフィールド。
SubType:
サブタイプ:
A 1-octet field that MUST be set to 0x04 to indicate "link-bandwidth".
「リンク帯域幅」を示すために 0x04 に設定しなければならない 1 オクテットのフィールド。
Global Administrator sub-field:
全体管理者のサブフィールド:
A 2-octet field that represents an operator-assigned 2-octet value. For example, this can be a 16-bit ASN.
オペレーターが割り当てた 2 オクテット値を表す 2 オクテットのフィールド。たとえば、これは 16 ビット ASN である可能性があります。
Local Administrator sub-field:
ローカル管理者のサブフィールド:
Bandwidth value (bytes per second) encoded as 4 octets in the 32-bit floating point format of [IEEE.754-2019].
[IEEE.754-2019] の 32 ビット浮動小数点形式で 4 オクテットとしてエンコードされた帯域幅値 (1 秒あたりのバイト数)。
The procedures cover both the transitive and non-transitive variants of the Link Bandwidth Extended Community so that implementations can handle both variants, ensuring that implementations can interoperate correctly across all deployments. Please refer to Section 5 and Appendix A for more details.
この手順では、リンク帯域幅拡張コミュニティの推移的バリアントと非推移的バリアントの両方をカバーしているため、実装は両方のバリアントを処理でき、実装がすべての展開にわたって正しく相互運用できることが保証されます。詳細については、セクション 5 および付録 A を参照してください。
A BGP speaker that attaches a Link Bandwidth Extended Community SHOULD be able to advertise either a transitive or a non-transitive Link Bandwidth Extended Community. Implementations SHOULD provide the configuration to set the transitivity type of the Link Bandwidth Extended Community, as well as the Global Administrator and bandwidth values in the Local Administrator sub-field, by using local policy. Different implementations MAY use different default values for the transitivity type of the Link Bandwidth Extended Community. The provided configuration SHOULD allow operators to override the default transitivity value as needed. Likewise, implementations SHOULD expose their default value.
リンク帯域幅拡張コミュニティを接続する BGP スピーカーは、推移的または非推移的なリンク帯域幅拡張コミュニティのいずれかをアドバタイズできる必要があります (SHOULD)。実装では、ローカル ポリシーを使用して、リンク帯域幅拡張コミュニティの推移性タイプ、およびローカル管理者サブフィールドのグローバル管理者と帯域幅値を設定するための設定を提供する必要があります (SHOULD)。実装が異なれば、リンク帯域幅拡張コミュニティの推移性タイプに異なるデフォルト値を使用してもよい(MAY)。提供された設定では、オペレータが必要に応じてデフォルトの推移性値をオーバーライドできるようにする必要があります (SHOULD)。同様に、実装はデフォルト値を公開すべきです(SHOULD)。
An implementation MAY advertise bandwidth value as zero. An operator may, for example, set the Link Bandwidth Extended Community to zero to indicate that the path should not attract traffic during maintenance. However, as per Section 3.2, it is up to the local policy of the receiver to decide how a link-bandwidth value of zero is handled.
実装は帯域幅値をゼロとしてアドバタイズしてもよい(MAY)。たとえば、オペレータは、リンク帯域幅拡張コミュニティをゼロに設定して、メンテナンス中にパスがトラフィックを引き付けるべきではないことを示すことができます。ただし、セクション 3.2 に従って、ゼロのリンク帯域幅値がどのように処理されるかは、受信側のローカル ポリシーによって決まります。
Generally, a single Link Bandwidth Extended Community of the transitivity type desired in a deployment is attached to a route. However, during transition (refer Section 7 for details), a BGP speaker MAY attach one Link Bandwidth Extended Community per transitivity (transitive/non-transitive); the bandwidth value included in both communities SHOULD be the same.
一般に、展開で必要な推移性タイプの単一のリンク帯域幅拡張コミュニティがルートに接続されます。ただし、移行中 (詳細についてはセクション 7 を参照)、BGP スピーカーは推移性 (推移性/非推移性) ごとに 1 つのリンク帯域幅拡張コミュニティを接続してもよい(MAY)。両方のコミュニティに含まれる帯域幅の値は同じであるべきです。
A Link Bandwidth Extended Community MAY be attached or updated for a BGP route upon receipt during Adj-RIB-In processing. The Link Bandwidth Extended Community MAY be attached or updated for a BGP route's Adj-RIB-Out entry while being advertised to a neighboring BGP speaker. (Adj-RIB-In and Adj-RIB-Out are as defined in [RFC4271].)
リンク帯域幅拡張コミュニティは、Adj-RIB-In 処理中の受信時に BGP ルートに接続または更新されてもよい（MAY）。リンク帯域幅拡張コミュニティは、隣接する BGP スピーカーにアドバタイズされている間に、BGP ルートの Adj-RIB-Out エントリに接続または更新されてもよい（MAY）。(Adj-RIB-In および Adj-RIB-Out は [RFC4271] で定義されているとおりです。)
Implementations MAY provide a configuration option to send non-transitive Link Bandwidth Extended Communities on external BGP sessions.
実装では、外部 BGP セッションで非推移的なリンク帯域幅拡張コミュニティを送信するための設定オプションを提供してもよい(MAY)。
A BGP receiver that supports the Link Bandwidth Extended Community MUST support processing of both the transitive and non-transitive types. The receiver MUST NOT flap or treat the route as malformed based on the transitivity of the Link Bandwidth Extended Community and/or BGP session type (internal versus external).
リンク帯域幅拡張コミュニティをサポートする BGP レシーバーは、推移型と非推移型の両方の処理をサポートしなければなりません (MUST)。受信者は、リンク帯域幅拡張コミュニティや BGP セッション タイプ (内部対外部) の推移性に基づいて、ルートをフラップしたり、不正な形式として扱ったりしてはなりません (MUST NOT)。
Implementations MAY provide configuration to accept non-transitive Link Bandwidth Extended Communities from external BGP sessions.
実装は、外部 BGP セッションから非推移的なリンク帯域幅拡張コミュニティを受け入れるための設定を提供してもよい (MAY)。
A BGP update with an attached Link Bandwidth Extended Community with a bandwidth value of zero is valid. When all contributing paths have a non-zero value in the Link Bandwidth Extended Community, the bandwidth values of those paths (or their ratio) can be utilized as weights to enable weighted load-balancing. Details of weighted load-balancing are outside the scope of this document. Refer to [LINK-BW-USE-CASES], which describes some of the weighted load-balancing aspects. However, in the case where the paths have a mix of zero and non-zero values, or all zero values, the behavior is determined by local policy. For example, implementations may exclude the paths with a zero value from weighted load-balancing formation as long as at least one path with a non-zero value exists, or they may fall back to equal load-balancing. The bandwidth value, however, SHOULD NOT be used as an input to the BGP best path selection process.
帯域幅値が 0 のリンク帯域幅拡張コミュニティが接続されている BGP アップデートは有効です。リンク帯域幅拡張コミュニティで寄与するすべてのパスがゼロ以外の値を持つ場合、それらのパスの帯域幅値 (またはその比率) を重みとして利用して、重み付けされたロード バランシングを有効にすることができます。加重負荷分散の詳細については、このドキュメントの範囲外です。[LINK-BW-USE-CASES] を参照してください。これには、重み付けされた負荷分散の側面のいくつかが説明されています。ただし、パスにゼロ値とゼロ以外の値が混在している場合、またはすべてゼロ値が含まれている場合、動作はローカル ポリシーによって決定されます。たとえば、実装では、ゼロ以外の値を持つパスが少なくとも 1 つ存在する限り、重み付けされた負荷分散形成から値がゼロのパスを除外することも、等しい負荷分散にフォールバックすることもできます。ただし、帯域幅の値は、BGP 最適パス選択プロセスへの入力として使用すべきではありません。
Between transitive and non-transitive types of Link Bandwidth Extended Communities that have the same bandwidth value, the transitivity does not matter for the purpose of computing weighted load-balancing or programming to the Forwarding Information Base (FIB).
同じ帯域幅値を持つリンク帯域幅拡張コミュニティの推移タイプと非推移タイプの間では、加重ロード バランシングの計算や転送情報ベース (FIB) へのプログラミングの目的では、推移性は問題になりません。
This section describes the procedures to be followed when a BGP speaker receives a route with an attached Link Bandwidth Extended Community and subsequently re-advertises that route.
このセクションでは、BGP スピーカーがリンク帯域幅拡張コミュニティが接続されたルートを受信し、その後そのルートを再アドバタイズするときに従う手順について説明します。
When a BGP speaker re-advertises a route received with a Link Bandwidth Extended Community and sets the next hop to itself or to another address, it MAY do any one of the following as its default behavior: remove the Link Bandwidth Extended Community, re-advertise it unchanged, or regenerate it with an updated value. Implementations SHOULD provide a local configuration method to alter their default behavior to the other options with per-session granularity. Likewise, implementations SHOULD expose their default value.
BGP スピーカーがリンク帯域幅拡張コミュニティで受信したルートを再アドバタイズし、ネクストホップを自身または別のアドレスに設定する場合、デフォルトの動作として、リンク帯域幅拡張コミュニティを削除するか、変更せずに再アドバタイズするか、更新された値で再生成するかのいずれかを行ってもよい(MAY)。実装は、デフォルトの動作をセッションごとの粒度で他のオプションに変更するためのローカル構成メソッドを提供すべきです(SHOULD)。同様に、実装はデフォルト値を公開すべきです(SHOULD)。
When regenerating the Link Bandwidth Extended Community, the same procedures as outlined in Section 3.1 apply. Please also refer to Section 3.4 for use in a BGP multipath environment.
リンク帯域幅拡張コミュニティを再生成する場合、セクション 3.1 で概説したのと同じ手順が適用されます。BGP マルチパス環境での使用については、セクション 3.4 も参照してください。
A BGP speaker that receives a route with a Link Bandwidth Extended Community and re-advertises or reflects the same without changing its next hop SHOULD NOT change the Link Bandwidth Extended Community in any way.
リンク帯域幅拡張コミュニティを持つルートを受信し、ネクストホップを変更せずに同じルートを再アドバタイズまたは反映する BGP スピーカーは、いかなる方法でもリンク帯域幅拡張コミュニティを変更してはなりません (SHOULD NOT)。
In a BGP multipath environment, the bandwidth value that is sent or re-advertised MAY be calculated based on the Link Bandwidth Extended Community associated with each constituent path contributing to multipath in the Local Routing Information Base (Local-RIB). This topic is beyond the scope of this document. Refer to [LINK-BW-USE-CASES], which describes how this could be done in specific scenarios.
BGP マルチパス環境では、送信または再アドバタイズされる帯域幅値は、ローカル ルーティング情報ベース (ローカル RIB) 内のマルチパスに寄与する各構成パスに関連付けられたリンク帯域幅拡張コミュニティに基づいて計算されてもよい(MAY)。このトピックは、このドキュメントの範囲外です。特定のシナリオでこれを行う方法については、[LINK-BW-USE-CASES] を参照してください。
If a BGP speaker receives a route with more than one Link Bandwidth Extended Community and uses the route to compute weighted load-balancing, it SHOULD use the extended community with the lowest bandwidth value (including zero), ignoring the transitivity. Implementations MAY provide configuration to change the above preference.
BGP スピーカーが複数のリンク帯域幅拡張コミュニティを持つルートを受信し、そのルートを使用して重み付きロード バランシングを計算する場合、推移性を無視して、最も低い帯域幅値 (0 を含む) の拡張コミュニティを使用する必要があります (SHOULD)。実装では、上記の設定を変更するための構成を提供できます (MAY)。
A negative value in a Link Bandwidth Extended Community SHOULD NOT be attached or originated by any BGP speaker. If a BGP receiver encounters a Link Bandwidth Extended Community that contains a negative link-bandwidth value, the Link Bandwidth Extended Community SHALL be ignored.
リンク帯域幅拡張コミュニティの負の値は、BGP スピーカーによって接続または発信されるべきではありません (SHOULD NOT)。BGP 受信者が、負のリンク帯域幅値を含むリンク帯域幅拡張コミュニティに遭遇した場合、そのリンク帯域幅拡張コミュニティは無視されるものとします (SHALL)。
Link Bandwidth Extended Communities with a zero value MUST NOT be considered malformed.
値がゼロのリンク帯域幅拡張コミュニティは、不正な形式であるとみなされてはなりません (MUST NOT)。
If any of the paths lack a valid Link Bandwidth Extended Community, equal load-balancing SHOULD be used unless overridden by local configuration.
いずれかのパスに有効なリンク帯域幅拡張コミュニティがない場合は、ローカル設定によってオーバーライドされない限り、均等な負荷分散を使用する必要があります (SHOULD)。
In the "Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry [IANA-TransExComm] (Type 0x00), IANA has updated Sub-Type 0x04 to:
「推移的な 2 オクテット AS 固有の拡張コミュニティ サブタイプ」レジストリ [IANA-TransExComm] (タイプ 0x00) で、IANA はサブタイプ 0x04 を次のように更新しました。
Name:
名前：
Link Bandwidth
リンク帯域幅
In the "Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry [IANA-Non-TransExComm] (Type 0x40), IANA has updated Sub-Type 0x04 to:
「非推移的な 2 オクテット AS 固有の拡張コミュニティ サブタイプ」レジストリ [IANA-Non-TransExComm] (タイプ 0x40) で、IANA はサブタイプ 0x04 を次のように更新しました。
Name:
名前：
Link Bandwidth
リンク帯域幅
Both updates reference this document.
どちらの更新もこのドキュメントを参照しています。
This extension to BGP has similar security implications as BGP extended communities [RFC4360].
この BGP への拡張には、BGP 拡張コミュニティ [RFC4360] と同様のセキュリティ上の影響があります。
The Link Bandwidth Extended Community conveys bandwidth and capacity information that may be sensitive. Exporting this community outside of an administrative domain can expose private network resource details. When propagating the routes with a Link Bandwidth Extended Community towards an untrusted network or outside of an administrative domain, it is recommended operators use policy to filter out this community.
リンク帯域幅拡張コミュニティは、機密性の高い帯域幅と容量の情報を伝達します。このコミュニティを管理ドメインの外にエクスポートすると、プライベート ネットワーク リソースの詳細が公開される可能性があります。リンク帯域幅拡張コミュニティを使用してルートを信頼できないネットワークまたは管理ドメインの外側に伝播する場合、オペレータはポリシーを使用してこのコミュニティをフィルタリングすることをお勧めします。
Prior deployments of the feature specified in this document have involved implementations that only understood one of the two extended community transitivity types. As a result, such implementations would ignore the other transitivity type that they don't understand. The procedures in this document govern how multiple transitivity types for bandwidth should operate.
このドキュメントで指定されている機能の以前の展開には、2 つの拡張コミュニティ推移性タイプのうちの 1 つだけを理解する実装が含まれていました。結果として、そのような実装は、理解できない他の推移性タイプを無視することになります。この文書の手順は、帯域幅の複数の推移性タイプがどのように動作するかを規定します。
Inconsistent behavior could occur when networks have deployed a mixture of implementations supporting this document's procedures for both transitivity types, or have deployed older implementations that only understand one transitivity type. A prime example is when a route received by a BGP speaker contains both a transitive and a non-transitive Link Bandwidth Extended Community, and that BGP speaker performs an operation that updates only one of the Link Bandwidth Extended Communities, so then the other community may have an inconsistent value. As a result, downstream BGP speakers that may receive such routes may perform inappropriate weighted load-balancing.
ネットワークが両方の推移性タイプに対してこのドキュメントの手順をサポートする実装を混合して展開した場合、または 1 つの推移性タイプのみを理解する古い実装を展開した場合、一貫性のない動作が発生する可能性があります。代表的な例は、BGP スピーカーが受信したルートに推移的および非推移的なリンク帯域幅拡張コミュニティの両方が含まれており、その BGP スピーカーがリンク帯域幅拡張コミュニティの 1 つだけを更新する操作を実行するため、もう一方のコミュニティの値が矛盾する可能性がある場合です。その結果、そのようなルートを受信するダウンストリーム BGP スピーカーは、不適切な重み付け負荷分散を実行する可能性があります。
To mitigate such issues, when operators are aware that older implementations are present in their networks, they may wish to take actions to address such inconsistencies. One option would be to filter the unsupported transitivity type of the Link Bandwidth Extended Community at advertisement time on the older BGP speaker, if the implementation is capable of such filtering. Alternatively, a receiving BGP speaker, knowing that the sending speaker is incapable of doing such operations, could strip the Link Bandwidth Extended Community type that is unsupported by the sender.
このような問題を軽減するために、通信事業者はネットワーク内に古い実装が存在することに気づいた場合、そのような不一致に対処するための措置を講じることを希望する場合があります。オプションの 1 つは、実装でそのようなフィルタリングが可能であれば、古い BGP スピーカーでのアドバタイズ時にリンク帯域幅拡張コミュニティのサポートされていない推移性タイプをフィルタリングすることです。あるいは、送信側スピーカーがそのような操作を実行できないことを知っている受信側 BGP スピーカーは、送信側がサポートしていないリンク帯域幅拡張コミュニティ タイプを削除する可能性があります。
Ideally, this operational consideration is short lived until all the routers in the network have been upgraded to implementations that consistently support the procedures in this document.
理想的には、この運用上の考慮事項は、ネットワーク内のすべてのルーターがこの文書の手順を一貫してサポートする実装にアップグレードされるまで短期間で終わります。
How the bandwidth value is computed or determined is out of scope of this document. Refer to [LINK-BW-USE-CASES], which describes how this could be done in specific scenarios. It is recommended that implementations provide mechanisms to limit the churn caused by frequently changing bandwidth values, because rapid fluctuations could impact protocol stability and network operations.
帯域幅の値がどのように計算または決定されるかについては、このドキュメントの範囲外です。特定のシナリオでこれを行う方法については、[LINK-BW-USE-CASES] を参照してください。急激な変動はプロトコルの安定性やネットワーク動作に影響を与える可能性があるため、帯域幅値の頻繁な変更によって引き起こされるチャーンを制限するメカニズムを実装に提供することをお勧めします。
[IEEE.754-2019]
IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, 22 July
2019, <https://ieeexplore.ieee.org/document/8766229>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[IANA-Non-TransExComm]
IANA, "Non-Transitive Two-Octet AS-Specific Extended
Community Sub-Types", <https://www.iana.org/assignments/
bgp-extended-communities>.
[IANA-TransExComm]
IANA, "Transitive Two-Octet AS-Specific Extended Community
Sub-Types", <https://www.iana.org/assignments/bgp-
extended-communities>.
[LINK-BW-USE-CASES]
Litkowski, S., Ed., Mohanty, S R., Ed., Vayner, A.,
Gattani, A., Kini, A., Tantsura, J., and R. Das, "BGP link
bandwidth extended community use cases", Work in Progress,
Internet-Draft, draft-ietf-bess-ebgp-dmz-10, 8 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
ebgp-dmz-10>.
The BGP Link Bandwidth Extended Community has evolved over several versions of the IETF draft. In the earlier versions up to draft-ietf-idr-link-bandwidth-08, only the non-transitive version of the Link Bandwidth Extended Community was supported. However, starting from draft-ietf-idr-link-bandwidth-09, both transitive and non-transitive versions of the Link Bandwidth Extended Community are supported.
BGP リンク帯域幅拡張コミュニティは、IETF ドラフトのいくつかのバージョンにわたって進化してきました。draft-ietf-idr-link-bandwidth-08 までの以前のバージョンでは、リンク帯域幅拡張コミュニティの非推移的バージョンのみがサポートされていました。ただし、draft-ietf-idr-link-bandwidth-09 以降では、リンク帯域幅拡張コミュニティの推移的バージョンと非推移的バージョンの両方がサポートされます。
A BGP speaker (sender or receiver) needs to be upgraded to support the procedures defined in this document to provide full interoperability for both transitive and non-transitive versions of the Link Bandwidth Extended Community. In order to simplify implementations, it is not a goal to provide interoperability by upgrading only the Route Reflector (RR).
BGP スピーカー (送信者または受信者) は、リンク帯域幅拡張コミュニティの推移的バージョンと非推移的バージョンの両方に完全な相互運用性を提供するために、この文書で定義されている手順をサポートするようにアップグレードする必要があります。実装を簡素化するために、ルート リフレクター (RR) のみをアップグレードして相互運用性を提供することは目的ではありません。
The authors would like to thank Yakov Rekhter, Srihari Sangli, and Dan Tappan for proposing unequal-cost load-balancing as one possible application of the extended community attribute. The authors would like to thank Jeff Haas for all the discussions and providing text for operational considerations.
著者らは、拡張コミュニティ属性の可能なアプリケーションの 1 つとして不等コスト負荷分散を提案してくださった Yakov Rekhter、Srihari Sangli、および Dan Tappan に感謝したいと思います。著者らは、すべての議論と運用上の考慮事項のテキストの提供について、Jeff Haas に感謝したいと思います。
The authors would like to thank Bruno Decraene, Robert Raszuk, Joel Halpern, Aleksi Suhonen, Randy Bush, Stephane Litkowski, Mankamana Mishra, Moshiko Nayman, Keon Vafai, Ketan Talaulikar, Yingzhen Qu, Anoop Ghanwani, Dongjie (Jimmy), and John Scudder for their comments and contributions.
著者らは、コメントと寄稿をいただいた Bruno Decraene、Robert Raszuk、Joel Halpern、Aleksi Suhonen、Randy Bush、Stephane Litkowski、Mankamana Mishra、Moshiko Nayman、Keon Vafai、Ketan Talaulikar、Yingzhen Qu、Anoop Ghanwani、Dongjie (Jimmy)、John Scudder に感謝します。
Kaliraj Vairavakkalai
HPE
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: kaliraj.vairavakkalai@hpe.com
Natrajan Venkataraman
HPE
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: natrajan.venkataraman@hpe.com
Rex Fernando
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: rex@cisco.com
Pradosh Mohapatra
Google LLC
Email: pradosh@gmail.com
Reshma Das (editor)
HPE
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: reshma.das@hpe.com
Satya Mohanty (editor)
Zscaler
120 Holger Way
San Jose, CA 95134
United States of America
Email: smohanty@zscaler.com
Serge Krier
Cisco Systems
Pegasus Parc, De Kleetlaan 6a
Belgium
Email: sekrier@cisco.com
Rafal Jan Szarecki
Google LLC
1160 N Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: rszarecki@gmail.com
Akshay Gattani
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America
Email: akshay@arista.com