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

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

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メッセージに結合する必要があります (SHOULD)。

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

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

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

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

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

BGP-4はBGP-3で適切に表現できない集約ルートを伝送できるため、BGP-4と別のBGPバージョンをサポートする実装は、ピアごとにBGP-4のみを話す機能を提供する必要があります (SHOULD)。

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

大量のパス情報を保持するパス集約アルゴリズムを提供することを選択する実装は、次の手順を使用することをお勧めします:

2つのルートのAS_PATH属性を集約する目的で、各ASを<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が両方のAS_PATH属性でYに先行する、または
Yが両方のAS_PATH属性でXに先行する。

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が1つの属性では直接連続するが、別の属性では連続しない場合、後者の介在するASはAS_SETパスセグメントに結合されます。このセグメントは、集約された属性の(a)で識別された2つの連続するASの間に配置されます。

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

上記の手順の結果として、特定のAS番号が集約されたAS_PATH属性内に複数回出現する場合、そのAS番号の最後のインスタンス（最も右の出現）を除くすべてを集約されたAS_PATH属性から削除する必要があります (SHOULD)。