多くの人がセグメント ルーティングとは何かについてまだ調査している中、SRv6 に続いて SRv6+ がアップされました。ここでは、SRv6+ の利点と、これを手に入れることが不可欠だと考えている理由についてご紹介します。
まず、今何が起きているのかという疑問が生じますが、SRv6+ とは何か、またその利点は何かについての理解が不足していると思われます。そこで、SRv6+ とは何か、その利点、これを手に入れることが不可欠な理由について説明します。
しかしまず始めに、一歩下がって、SRv6 とは何かについて簡単に説明します。実質的に、セグメント ルーティングにはさまざまな種類のセグメント識別子があります（https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02 を参照）。それらすべてについて詳しくは説明しませんが、今日の SR のほとんどが、Type 1 SID （基本的に MPLS ラベル）を使用していると言えば十分でしょう。Type 3 SID の中には、波長無依存 SR の第 1 ホップの TE パス生成用に使われているものもあります。その他の SID タイプの中には、より多くの SR ベースの素材が開発されるにつれて使われるようになってきたものもありますが、それは顕著な事例です。
ただし SRv6 は、拡張ヘッダーでラベルの代わりに IPv6 アドレスを使用します。これらはルーティング拡張ヘッダーに配置され、スタックされます。SRH は 64 ビットの「ヘッダー」と、スタックされた v6 SID で構成されます。つまり、最低でも、SRv6 パケットには 192 ビットの追加データがあるということです。ちなみに、MPLS ヘッダーの長さは 32 ビットです（20 ビットのラベル + 3 ビットのトラフィック クラス + 1 ビットのボトム スタック + 8 ビットの TTL）。このためオーバーヘッドがかなり大きくなります。ラベルを 4 階層スタックすると、オーバーヘッドが大きくなりすぎてしまいます。また、SRv6 は IPv6 アドレス（IPv4 アドレスではない）も効果的に使用します。その結果、V6 アドレスの過負荷が発生します。現状ではこの結果を十分に評価することはできませんが、IPv6 アドレスによって、ますます厄介なことになるのではないかと感じています。
それはさておき、続いて SRv6+ の話をしましょう。これは実質的に 4 つのドラフトの組み合わせから成り、それぞれ以下で確認できます。
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-03
https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-05
https://tools.ietf.org/html/draft-bonica-6man-oam-03
1 番目のドラフトでは、標準の v6 セグメント ルーティング ヘッダーを CRH（圧縮ルーティング ヘッダー）に置き換えています。CRH は、8 ビット長、16 ビット長、32 ビット長いずれかの SID のリストを使い、これらの SID は IPv6 アドレスにマッピングされます。この仕組みについては、今後の投稿で詳しく説明するつもりですが、従来の SRH による大きなオーバーヘッドがなくなると言えば十分でしょう。実際、健全なオペレーターなら受け入れられないオーバーヘッドなしで、SRv6 が実行可能になります。
2 番目のドラフトでは、ソース ノードによって IPv6 アドレスから中間ノードに送信される命令を分離します。基本的に、通常の SRv6（ https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05 を参照）では、セクション 4 にあるように、SID と関連付けることができる非常に多くの関数が定義されています。ここでは、V6 SID は V6 アドレスなので、これが行うことはアドレスの過負荷になるということに注意してください。ただし、セグメント終了オプションのドラフトには、アドレス スペースに過負荷をかけることなく、命令などの情報を運ぶヘッダー（オプション）があります。
3 番目のドラフトでは、MPLS ラベルを処理できないけれど、引き続き VPNv6 を必要とするデバイス向けに、VPN コンテキスト情報を運ぶ非 MPLS ラベル手法を効率的に作成します（これについては、今後の記事で詳しく説明する予定です）。
4 番目の RFC では、組み込み OAM 命令が可能です。基本的にソース ノードは、特定の処理（パケットのログ記録、パケット数のカウント、ICMPv6 OAM パケットをソースに戻す、特定の遠隔データをコレクターに戻すなど）を実行するように深いパスにあるノードに命令できます。SR がステートレスであることを考慮すると、このような命令を組み込むことができることにより、興味深い、そして実際に役に立つ用途がいくつかあります。たとえば、パス上の各ノードに、パケットの到着時刻およびパケットそのものを含む遠隔データを送信するように命令したとすると、各ノードから受信したデータを関連付けて、パス上のノード間の、リアルタイムの遅延メトリックを効果的に提供するといったことができます。
したがって、これは SRv6+ についての特訓コースです。SRv6+ はなぜ必要なのでしょうか？SRv6 によるオーバーヘッドは許容できないからです。IPv6 アドレスによる過負荷は合理的ではなく、危険が伴います。また OAM RFC が提供する OAM オプションにより、コントローラや機械学習などがネットワークでますます利用されるようになってきている中、非常に興味深い可能性がもたらされます。
これがどのように進化するかを目にするのは興味深いものがあります。これらのドラフトの一部は修正され、何らかの改良がなされると思いますが、MPLS Global Forum などで私が見たことから判断すると、SRv6 は導入され、どういった形式になるかというのが唯一の疑問だと言えます。私はコスト的な観点からも、アドレス スペースに異常なオーバーヘッドや過負荷をかけず、オーバーヘッドに対処するためだけにルーターのインターフェイスのアップグレードを強制することがない仕組みを支持しています。
