Appendix F. Implementation Recommendations (付録F. 実装の推奨事項)

このセクションでは、いくつかの実装の推奨事項を提示します。

Appendix F.1. Multiple Networks Per Message (メッセージあたりの複数のネットワーク)

BGPプロトコルでは、同じパス属性を持つ複数のアドレスプレフィックスを1つのメッセージで指定できます。この機能を使用することを強く推奨します。メッセージあたり1つのアドレスプレフィックスでは、受信側でオーバーヘッドが大幅に増加します。複数のメッセージの受信によりシステムオーバーヘッドが増加するだけでなく、BGPピアや他のルーティングプロトコルへの更新のためにルーティングテーブルをスキャンするオーバーヘッド（および関連するメッセージの送信）も複数回発生します。

パス属性セットごとに編成されていないルーティングテーブルから、パス属性セットあたり多くのアドレスプレフィックスを含むメッセージを構築する1つの方法は、ルーティングテーブルがスキャンされるときに多くのメッセージを構築することです。各アドレスプレフィックスが処理されると、関連するパス属性のセットに対するメッセージが存在しない場合は割り当てられ、新しいアドレスプレフィックスがそれに追加されます。そのようなメッセージが存在する場合、新しいアドレスプレフィックスがそれに追加されます。メッセージに新しいアドレスプレフィックスを保持するスペースがない場合、それは送信され、新しいメッセージが割り当てられ、新しいアドレスプレフィックスが新しいメッセージに挿入されます。ルーティングテーブル全体がスキャンされると、すべての割り当てられたメッセージが送信され、そのリソースが解放されます。アドレスプレフィックスでカバーされるすべての宛先が共通のパス属性セットを共有している場合、最大の圧縮が達成され、1つの4096バイトメッセージで多くのアドレスプレフィックスを送信することが可能になります。

複数のアドレスプレフィックスを1つのメッセージに圧縮しないBGP実装とピアリングする場合、ピアが取得されたときや重大なネットワークトポロジ変更が発生したときに受信するデータの洪水からのオーバーヘッドを減らすための措置を講じる必要がある場合があります。これを行う1つの方法は、更新のレートを制限することです。これにより、BGPピアや他のルーティングプロトコルにフラッシュ更新を提供するためにルーティングテーブルを冗長にスキャンすることがなくなります。このアプローチの欠点は、ルーティング情報の伝播遅延が増加することです。複数のメッセージを処理するのにかかる時間よりもはるかに大きくない最小フラッシュ更新間隔を選択することで、この遅延を最小限に抑えることができます。より良い方法は、更新を送信する前にすべての受信メッセージを読み取ることです。

Appendix F.2. Reducing Route Flapping (ルートフラッピングの削減)

過度のルートフラッピングを避けるために、宛先を撤回してより具体的またはより一般的なルートについての更新を送信する必要があるBGPスピーカーは、それらを同じUPDATEメッセージに結合すべきです。

Appendix F.3. Path Attribute Ordering (パス属性の順序付け)

更新メッセージを結合する実装（上記のセクション6.1で説明）は、すべてのパス属性が既知の順序で提示されることを好む場合があります。これにより、意味的に同一の異なる更新メッセージからの属性セットを迅速に識別できます。これを容易にするために、パス属性をタイプコードに従って順序付けることは有用な最適化です。この最適化は完全にオプションです。

Appendix F.4. AS_SET Sorting (AS_SETのソート)

この状況を簡素化するために行うことができるもう1つの有用な最適化は、AS_SETに見つかったAS番号をソートすることです。この最適化は完全にオプションです。

Appendix F.5. Control Over Version Negotiation (バージョンネゴシエーションの制御)

BGP-4はBGP-3で適切に表現できない集約ルートを運ぶことができるため、BGP-4と別のBGPバージョンをサポートする実装は、ピアごとにBGP-4のみを話す機能を提供すべきです。

Appendix F.6. Complex AS_PATH Aggregation (複雑なAS_PATH集約)

相当量のパス情報を保持するパス集約アルゴリズムを提供することを選択する実装は、次の手順を使用することを望むかもしれません：

2つのルートのAS_PATH属性を集約するために、各ASをAS_PATH属性内のタプル<type, value>としてモデル化します。ここで、「type」はASが属するパスセグメントのタイプを識別し（例：AS_SEQUENCE、AS_SET）、「value」はAS番号です。対応する<type, value>タプルが同じ場合、2つのASは同じと言われます。

2つのAS_PATH属性を集約するアルゴリズムは次のように動作します：

a) 両方のAS_PATH属性内で同じ相対順序にある各AS_PATH属性内の同じAS（上記で定義）を識別します。2つのAS、XとYは、次のいずれかの場合に同じ順序にあると言われます：

XがYに両方のAS_PATH属性で先行する、または
YがXに両方のAS_PATH属性で先行する。

b) 集約されたAS_PATH属性は、(a)で識別されたASで構成され、集約されるAS_PATH属性に表示される順序とまったく同じ順序です。(a)で識別された2つの連続するASが、集約されるAS_PATH属性の両方ですぐに続かない場合、両方の属性の介在するAS（同じ2つの連続するASの間にあるAS）は、両方のAS_PATH属性からの介在するASで構成されるAS_SETパスセグメントに結合されます。次に、このセグメントは、集約された属性の(a)で識別された2つの連続するAS間に配置されます。(a)で識別された2つの連続するASが一方の属性ですぐに続くが、もう一方では続かない場合、後者の介在するASはAS_SETパスセグメントに結合されます。次に、このセグメントは、集約された属性の(a)で識別された2つの連続するAS間に配置されます。

c) 集約されたAS_PATH内の隣接するタプルの各ペアについて、両方のタプルが同じタイプを持つ場合、255を超える長さのセグメントが生成されない限り、それらを一緒にマージします。

上記の手順の結果として、指定されたAS番号が集約されたAS_PATH属性内に複数回表示される場合、そのAS番号の最後のインスタンス（最も右の出現）を除くすべてが、集約されたAS_PATH属性から削除されるべきです。