メインコンテンツまでスキップ

6. Manageability Considerations (管理性に関する考慮事項)

6. Manageability Considerations (管理性に関する考慮事項)​

このセクションは [RFC5706] で推奨されているように構成されています。

既存の BGP 運用手順が適用されます。本文書では新しい運用手順は定義されていません。本文書に存在する NLRI 情報は, 転送状態に直接的な対応する影響を持たない純粋にアプリケーションレベルのデータを運ぶことに注意してください。そのため, 到達可能性情報の変動は, ルーター全体の転送状態を変更する必要がある通常の BGP 更新とは異なる影響を及ぼします。さらに, この NLRI の配信は, 異なる NLRI タイプ間である程度の分離と障害封じ込めを提供する専用のルートリフレクターによって処理されることが予想されます。

セクション 6.2.3 で定義された構成パラメータは, 次のデフォルト値に初期化されるべきです (SHOULD):

  • すべてのネイバーに対してリンクステート NLRI 機能がオフになります。

  • リンクステート NLRI がネイバーからアドバタイズ/撤回される最大レートは, 毎秒 200 更新に設定されます。

提案された拡張は, 機能ネゴシエーション後にのみ BGP ピア間でアクティブ化されます。さらに, 拡張は個別のピアベースでオン/オフにできる (セクション 6.2.3 参照) ため, ネットワークで段階的にロールアウトできます。

本文書で定義されたプロトコル拡張は, 他のプロトコルまたは機能コンポーネントに新しい要件を課しません。

リンクステート NLRI 更新の頻度は, 通常の BGP プレフィックス配信を妨げる可能性があります。ネットワークオペレーターは, リンクステート NLRI を配信するために専用のルートリフレクターインフラストラクチャを使用してもよい (MAY) です。

リンクステート NLRI の配信は, AS 内の複数のエリアまたは複数の AS で構成できる単一の管理ドメインに制限されるべきです (SHOULD)。

既存の BGP 手順が適用されます。さらに, 実装はオペレーターが次のことを行えるようにすべきです (SHOULD):

  • スピーカーがリンクステート NLRI を交換しているネイバーをリストする。

IDR ワーキンググループは, BGP スピーカーとそれらの間のセッションを管理および監視するための管理情報ベースと YANG モデルの一部を文書化し, 引き続き文書化しています。現在, BGP-LS を実行している BGP セッションは他の BGP セッションと実質的に異なるものではなく, 同じデータモデルを使用して管理できると考えられています。

BGP-LS の実装が不正な形式の属性を検出した場合, [RFC7606] のセクション 2 に従って 'Attribute Discard' アクションを使用しなければなりません (MUST)。

BGP-LS の実装は, メッセージが不正な形式かどうかを判断するために次の構文チェックを実行しなければなりません (MUST)。

  • BGP-LS 属性で見つかったすべての TLV の合計は, BGP-LS パス属性長に対応していますか?

  • BGP MP_REACH_NLRI 属性で見つかったすべての TLV の合計は, BGP MP_REACH_NLRI 長に対応していますか?

  • BGP MP_UNREACH_NLRI 属性で見つかったすべての TLV の合計は, BGP MP_UNREACH_NLRI 長に対応していますか?

  • ノード, リンク, またはプレフィックス記述子 NLRI 属性で見つかったすべての TLV の合計は, ノード, リンク, またはプレフィックス記述子の Total NLRI Length フィールドに対応していますか?

  • 固定長 TLV は本文書の TLV Length フィールドに対応していますか?

実装は, オペレーターがリンクステート NLRI がアドバタイズされるネイバーおよびリンクステート NLRI が受け入れられるネイバーを指定できるようにすべきです (SHOULD)。

実装は, オペレーターがリンクステート NLRI がネイバーからアドバタイズ/撤回される最大レートを指定できるようにすべきです (SHOULD)。

実装は, オペレーターがルーターのルーティング情報ベース (Routing Information Base, RIB) に格納されるリンクステート NLRI の最大数を指定できるようにすべきです (SHOULD)。

実装は, オペレーターがネイバーにアドバタイズされる抽象化されたトポロジを作成し, 異なるネイバーに対して異なる抽象化を作成できるようにすべきです (SHOULD)。

実装は, オペレーターが 64 ビット Instance-ID を構成できるようにすべきです (SHOULD)。

実装は, オペレーターがノードが参加するフラッディングセットごとに ASN と BGP-LS 識別子のペア (セクション 3.2.1.4) を構成できるようにすべきです (SHOULD)。

該当なし。

実装は次の統計を提供すべきです (SHOULD):

  • 送信/受信されたリンクステート NLRI 更新の総数

  • ネイバーごとに送信/受信されたリンクステート NLRI 更新の数

  • ネイバーごとに受信されたエラーのあるリンクステート NLRI 更新の数

  • ローカルで発信されたリンクステート NLRI の総数

これらの統計は, システムまたはセッションの開始時間からの絶対カウントとして記録されるべきです。実装は, 各ケースで毎秒のピークカウントを記録することにより, この情報を強化してもよい (MAY) です。

に最終更新