要約

  • RFC 10005は、BGP Link Bandwidth Extended Communityに毎秒バイト単位の4オクテット浮動小数点値を格納する形式を定めるが、値の決定方法と重み付き負荷分散のアルゴリズムは定めない。
  • ゼロ、欠落、複数値、transitive属性、next hop変更時の扱いは実装既定値とローカル方針に依存する。正しい属性だけでは、現在の利用可能容量、FIBの重み、実効スループットを証明できない。
  • Pradosh Mohapatraは6人の著者の一人である。この共同成果が標準化するのは狭い運搬手段であり、運用上の真実には起源から転送結果までの追跡可能な記録が要る。

同じ値が残る場面ほど、系譜は失われやすい。ルータAから50を受けたルータBがnext hopを書き換え、そのまま50を保持したのかもしれない。あるいは、Bがローカルリンクと遠隔集約を比較し、自分の方針で新たな50を作ったのかもしれない。下流のルータCが見る最終値からは区別できない。

この違いは障害時に表面化する。保持なら上流の測定や設定の鮮度を問うべきだ。再生成ならBの入力、制限関数、方針バージョンを問うべきだ。数字だけを保存した監視系は、問い合わせ先さえ決められない。

2026年6月にIETF Standards Trackとして公開されたRFC 10005は、BGP Link Bandwidth Extended Communityを規定する。著者はPradosh Mohapatra、Reshma Das、Satya Mohanty、Serge Krier、Rafal Jan Szarecki、Akshay Gattaniの6人である。文書は相互運用可能な形式と処理を定める一方、値の計算と負荷分散方式を明確に範囲外へ置く。

値の形式は意味より厳密である

Communityにはtransitiveのタイプ0x00とnon-transitiveのタイプ0x40があり、sub-typeは0x04である。2オクテットのGlobal Administratorに続き、4オクテットのLocal Administratorが入る。後者はIEEE 754単精度浮動小数点で、単位は毎秒バイトである。

毎秒ビットではない。表示系がbit/sへ変換するなら8倍という処理が入り、さらにGbit/sへ丸めれば別の変換が加わる。元のビット列、デコード値、単位、表示変換を分けて残さなければ、後からBGP属性と画面表示を照合できない。

形式が精密でも、意味を示すタグはない。値はインターフェース速度かもしれず、遠隔経路の合計かもしれず、設定した希望値やサーバ数由来の重みかもしれない。瞬時の空き容量、混雑を除いた利用可能量、配送済みスループットであるとは限らない。RFC 10005は、値をどう計算または決定するかを規定しない。

したがって、同じ単位を持つ値同士でも、そのまま加算できるとは限らない。意味の分類、生成元、測定または設定方法、観測時刻、有効期間、所有者が別記録として必要になる。Communityが運ぶのは数値であり、その数値の出生証明ではない。

Global Administratorは署名ではない

2オクテットのGlobal Administratorには、Communityを付けたルータのASNを入れることが推奨される。ただし、任意の2オクテット値を置ける。4オクテットASNは収まらず、AS_TRANSを用いる。このフィールドはCommunityの用途や意味を変えない。

つまり、測定者、承認者、容量所有者を確定する認証情報ではない。送信者の実体は、BGPセッション、neighbor、address family、管理ドメイン、属性付与イベントと結び付けて保存する必要がある。2オクテットを人や組織の権限へ読み替えてはならない。

transitiveかnon-transitiveかは伝播範囲に関わる。移行中、古い実装が片方だけを理解し、一方のコピーが更新され、もう一方が古いまま残ることがある。下流では認識可能な二つの値が並び、不適切な重みが計算され得る。

監視は選ばれた一値だけでなく、全コピーのタイプ、raw value、受信時刻を比較すべきだ。異なるtransitivityで異なる値があれば、表示上の統合ではなく調査対象である。

next hop変更には三つの動詞がある

RFC 10005では、再広告でnext hopを変更するspeakerは、Communityをremove、retain、regenerateのいずれかにできる。実装は既定動作を公開し、セッション単位で上書き可能にするべきだ。next hopが変わらない場合、Communityを変更すべきではない。

removeは、上流の宣言を下流判断へ使わせない選択である。retainは、宣言を運ぶがローカル証拠を追加しない。regenerateは、ローカル入力を用いた新しい主張である。値が同じでも動詞が違えば、責任者と鮮度が違う。

境界記録には、変更前後のnext hop、入力値、動詞、方針バージョン、ローカル入力、出力値、時刻、実行主体が必要だ。これがなければ、最終値から途中の判断を逆算することはできない。

2026年4月版のdraft-ietf-bess-ebgp-dmz-10は、この判断を具体化するInternet-Draftであり、最終RFCではない。遠隔の70 Gbit/sを、next hopへ至るローカル50 Gbit/sで制限する例を示す。遠隔帯域、ローカルリンク、計算後のcontributing bandwidthを分ける発想は監視設計に役立つが、RFC 10005の保証を拡張するものではない。

ゼロを「何もない」と扱わない

ゼロは有効な値であり、保守時に使うことができる。受信側は、ゼロ経路を除外する、equal load-balancingへ戻す、別の設定方針を適用する、といった選択を持つ。全経路がゼロの場合にも、一つの普遍的意味はない。

欠落は別である。multipathの一つに有効なCommunityがなければ、設定で変えない限りequal load-balancingが既定となる。負値は発信すべきではなく、受信側で無視される。期限を過ぎた正値は形式上有効でもstaleである。

ゼロ、欠落、無効、staleを一つのunknownへまとめると、原因と対応が消える。計画的drain、機能非対応、誤ったorigin、更新抑制は別の障害面を持つ。

一つのrouteに複数のLink Bandwidth Communityがある場合、weighted load-balancingへ用いる既定動作は、ゼロを含む最小値の選択である。設定で変更できる。証拠には候補すべてと選択規則を残し、画面に出た値だけを唯一の入力として扱わない。

受信計算からパケットまでには距離がある

全contributing pathが非ゼロ値を持つとき、値または比率を重みとして利用できる。具体的なアルゴリズムはRFCの範囲外であり、BGP best-path selectionへの入力には使うべきでない。選ばれたmultipath集合の間で、別の処理が分配を決める。

ソフトウェアが1対2を計算しても、FIBは限られたbucketで近似するかもしれない。hardwareはresilient hashingのため既存flowを維持するかもしれない。大flowが少数あるだけで、byte shareはbucket比率から外れる。

そこで、受信Community、計算weight、FIBまたはECMPの実装weight、pathごとの実トラフィックを同じgenerationで結ぶ。control-planeのshow結果はhardware acknowledgementの代わりにならず、hardware状態はtraffic observationの代わりにならない。

さらに、均等に分散できたことと容量が足りることは別だ。interface line rate、到達可能なbottleneck、現在のheadroom、実効throughputを区別する。loss、latency、queue depth、congestionを見ずに、比率だけを成功指標にしてはならない。

安定化は別の時計を作る

値が頻繁に変わると、protocol stabilityと運用に影響する。RFC 10005はchurnを抑える仕組みを推奨する。thresholdやtimerは妥当だが、source observationとBGP advertisementの間に遅延を作る。

観測、広告判断、送信、受信、policy calculation、hardware installationの時刻を別々に保存する。抑制された更新も履歴として残す。最後に受けた時刻だけでは、元データの年齢を説明できない。

容量情報には機密性もある。管理ドメイン外や信頼できないnetworkへ向かうrouteではpolicy filteringが推奨される。どの境界で、どのversionの規則が、何を削除し、どの例外を通したかまで確認して初めて、保護が実行されたと言える。

Pradosh Mohapatraの記録が示す範囲

RFC 10005はPradosh Mohapatraの所属をGoogle LLCとし、5人の共著者とともに記載する。2026年9月1日に取得した公式Datatracker参加者記録は11件のRFCを掲載する一方、旧表記の「Prodosh Mohapatra」を表示していた。RFCと公開ipSpace著者ページが使う「Pradosh Mohapatra」を、本稿では正規の本人名とする。

ipSpaceの履歴は、Cumulus NetworksとCiscoでの過去のrouting software職歴を日付付き文脈として示す。RFC記載以上の現在の役職、IETF合意への支配、特定operatorの導入結果を証明するものではない。

人物を軸にしても、6人の標準を一人の発明へ変えてはならない。ここで確認できる貢献は、Mohapatraと共著者が小さなcarrierの動作を明確にし、その外側にあるローカル判断をローカル判断のまま残したことだ。

値を終点まで追跡する

route、address family、neighbor、管理ドメイン、transitivity、Global Administrator、raw bytes、decoded bytes per second、表示変換から記録を始める。意味、source method、観測時刻、有効期間、所有者を結ぶ。

next hop境界ごとにremove、retain、regenerateを残す。集約では構成path、zero・missing・invalidの扱い、式を残す。受信ではpolicy versionと計算比率、実行ではFIB、hardware acknowledgement、path別trafficを残す。

最後にbytes、loss、latency、queue、alarm、判断、rollback、stale cleanupを同じ記録へ結ぶ。Communityはrouting inputとして有用であり続ける。「利用可能容量」は、その4オクテットが運ばなかった証拠まで確認した後にだけ使える言葉である。

出典