ラベルからルートへのマッピング、ラベル生成のスケーラビリティ

MPLS対応のルーターでは、ルーティングテーブルの宛先プレフィックスごとに一意のラベルが生成されますか、それとも両方ではない場合、ルーティングテーブルのネクストホップごとに一意のラベルが生成されますか？また、Destinationプレフィックスごとの場合、どれくらい拡張可能ですか？私の理解によると、最大ラベル値は2 ^ 20 = 1048576です。ルーティングテーブルエントリの数が1048576を超えるとどうなりますか？

ルーティングテーブルの宛先プレフィックスごとに生成される一意のラベルですか、それともルーティングテーブルのネクストホップごとですか？...私は100万のルートに近づく顧客シナリオを見ました...しかし、MPLSにはラベル生成のための共通のガイドラインがありませんか？一意のラベルを宛先プレフィックスごとまたはネクストホップごとに生成する必要があることを示す一般的なルールはありませんか？それとも実装固有ですか？

少し混乱があるようです。誰かがインターネットルートごとに一意のラベルを割り当てようとする可能性はかなり低いです。適切に設計されたMPLSネットワークは、BGPネクストホップにバインドされているIGPプレフィックスに基づいてラベルを割り当てる必要があります（RFC 3031、セクション4.6を参照）。

そのため、今日のLFIBの100万ラベルがMPLS設計の重大な制約であるかどうかはよくわかりません。

ラベルがなくなる可能性がある実際のシナリオは、議論の余地があります。いくつかのハウスキーピングの問題もあります。これらは、ラベルの不足とは直接関係していませんが、その影響の一因です。

今日の主要ベンダー（少なくともCSCO、JNPR）のラベルマネージャーは、ラベルアプリケーションごとに継続的なブロックが必要になるようにプログラムされています。もちろん、これは修正でき、パフォーマンスと複雑さが多少犠牲になりますが、検討すべきもう1つの問題です。

一部のMPLSサービスは、コアのラベルスペースに非常に飢えています。エッジでは、「IGPラベル」でマスクできるため、ほとんど関係ありません。
MPLSはIPだけでなくFECでもあることを覚えておく必要があります。コアで異なる処理/パスをサービスに提供する必要がある場合は、新しいFECが必要です。

メガラベルとビッグラベル、およびそれらの使用例のサポートについてはいくつかの議論がありますが、実装は特別な目的のラベルを使用する可能性が高くなります。個人的には、2 ^ 20が問題になる前にMPLSワイヤー形式が変更されることを期待/期待しています。MPLSは主に1つの事業者ネットワーク内でのみ使用されるため、IPv4-> IPV6の移​​行と比較して、ワイヤー形式の変更は非常に簡単です。そのため、私たちが遭遇する問題の対処は非常に簡単です。解決したいいくつかの問題：

1. ラベルの履歴を転送中に保持する機能
2. 低バイトオーバーヘッド（スタックラベルではTTL、TCは冗長です）
3. トランジットPの「ダックタイピング」MPLSペイロードの必要性を排除（今日のECMPに違反）
4. 設計により拡張可能（特別な目的のラベルは莫大なバイトコストをもたらす）
5. ラベルスペースの増加
6. MPLSv1との共存