こんにちは。テックリード でモバイルコアを開発しているチームのリーダーの日下部 (@higebu ) とチームメンバーの早坂 (@takemioIO ) です。
IETF 116 Hackathon にて、以下の二つのHackathon に参加してきましたので何をしてきたのかなどをご報告したいと思います。
BGP-MUP SAFI Implementation and Interop (日下部、早坂)
SRv6 Data-Plane Visibility (早坂)
IETF 116 Hackathon について知らない方もいると思いますので、簡単に紹介すると、無料で参加できる IETF 116 の中のイベントの1つで、RFC 、ドラフトの著者などと開発者や運用をしている人などが集まって、実装してみたり、相互接続テストをしてみたりして、仕様に対する理解を深めたり、議論したりするための場です。
今回は 3/25（土）（9時30分~20時）と3/26（日）（9時30分~13時, 14時から結果報告）の2日間開催され、会場はパシフィコ横浜 ノースでした。
飲み物、昼食、夕食（ビール付き）も無料で供給され、ずっと会場でハッカソン していられるようになっており、スポンサー企業やスタッフの皆様にはとても感謝しております。
スケジュールやスポンサー企業について、詳しくは IETF 116 Hackathon Wiki を見てください。
IETF 116 Hackathon Project Map
BGP-MUP SAFI Implementation and Interop について
BGP-MUP SAFI Implementation and Interop
標準化中の BGP-MUP SAFIのインターネットドラフト を参考に実装した製品やOSS を持ち寄って相互接続テストを行ったり、詳細な仕様を確認したり、バグを直したりする会です。
詳しくは IETF 116 Hackathon WikiのBGP-MUP SAFI Implementation and Interop を参照してください。
BBSakuraから参加した二人は下記の3つのOSS 実装で参加しました。以下に参加開始時点での実装状況と実装者を示します。
GoBGPでの実装については下記の記事もご参照ください。
blog.bbsakura.net
他に、Arrcusさん、Cisco さん、Furukawaさんの開発版の製品がエントリーされていました。
BGP-MUP SAFI Implementation and Interop のハッカソン の様子
1日目
Breakfast
簡単な挨拶と、各チームの紹介の後、相互接続テストの結果を書くスプレッドシート と、テスト環境として使う CML2 (Cisco Modeling Labs ) へのアクセス方法が共有されました。
相互接続テストをすぐに始められるようにするため、日下部と早坂は事前にCML2でGoBGPやExaBGPを動かすための cloud-init の YAML ファイルを作っていました。
（補足：CML2で使えるUbuntu イメージは cloud-init によってネットワークの設定やパッケージのインストールなどが行えるようになっています。）
しかし、今回利用したのが3/3にリリースされたばかりの CML 2.5 で、普段使っていたのが CML 2.4 だったためか、 GoBGP, ExaBGPを動かすためのcloud-init がうまく動かず、何とか動かないかと格闘しているうちに、午前中が終了しました。。。
結局、 cloud-init では default_user cisco の設定と、ネットワークの設定のみに絞ってVM を起動し、コンソールから GoBGP などをインストールする方式に変更しました。
最終的な cloud-init のYAML やGoBGP, ExaBGPのコンフィグやアンチョコは下記のgistに記載しています。
FRRについては前述の通り動作がまだ不完全だったため、Hackathon らしく現地で開発をしていました。
そのために並行して、SoftBank の藤田さんに開発に参加してもらい、FRRのデバッグ を進めていただくため、開発環境を整えていただいていました。
いろいろやっているうちに、昼ご飯のカレーがなくなっていたことが悲しかったのを覚えています。
午後にとある実装と接続テストを行ったところ、Attribute Length Errorが返されてしまいました。
そこで、いろいろと切り分けをしていった結果、Next hopをIPv6 アドレスにするとType 2、3、4（Direct Segment Discovery Route、Type 1 & 2 Session Transformed Route）は受け取ってもらえることがわかりました。
さらに Type 1(Interwork Segment Discovery Route) では Prefix が IPv4 の場合は /32、 IPv6 の場合は /128 のみ受け取ることができるということがわかりました。
この仕様の認識の違いは翌日には修正されていました。スピード感が早くHackathon らしいなと非常に驚きました。
FRRの状況はさらにSoftBank の堀場さんがCML2上で開発に途中参戦し、夜までには Type 3、4（Type 1 & 2 Session Transformed Route）の受信ができるようになっていました。
そのときのコミットが こちら です。
2日目
前日に問題があった実装との相互接続テストを実施し、問題が解消されていることを確認していきました。
当日はType 4(Type 2 Session Transformed Route)に含まれるTEIDの処理に問題があった実装もあり、仕様に関する認識の違いもありましたが最終的には相互接続を達成しました。
Arrcusさんでは ルートリフレクタとしても動作するMUP-CとMUP-GW、MUP-PEを用意し、MUP-C経由でMUP-GWやMUP-PEにRoute Targetを使って、Type 3、4（Type 1 & 2 Session Transformed Route）の経路情報がimportされるように設定されていて、さすがだなと思いました。
また、FRRの開発では、慶応SFC の澤田さんも参加し、主に Prefix Length の扱いについてソースを追って、正しい実装はどうなるかを考えていました。
最終的にFRRを除いた他の実装については全ての Route Type の相互接続テストをパスできました。
FRRについては、Type 3、4（Type 1 & 2 Session Transformed Route）を10個ずつ受けても1個しか表示されないという状態からスタートでしたが、SoftBank の堀場さん、藤田さん、慶応SFC の澤田さんのお力で全て表示されるところまで進みました。ありがとうございました 🙇
FRRのBGP-MUP SAFI対応は完成までまだまだやることがたくさんある状態なので、引き続き協力してくれた方々と一緒に実装していきたいと思っています。
BGP-MUP SAFI Implementation and Interop の結果
前述の通りFRR以外の全ての実装が相互接続を完了することができました！
Project results presentations については松嶋さんの発表資料を貼っておきますので、こちらをご参照ください。
このハッカソン からBGP-MUP開発者が勘違いや失敗しやすい注意点の洞察も得れました。
以下にその知見を共有したいと思います。
RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop は RFC 5549 が更新されたものです。
今回のテスト環境ではBGPのトランスポートプロトコル がIPv6 です。
しかし広報する経路情報に含まれるプレフィックス がIPv4 (つまりAFIがIPv4 )の場合があります。その場合にNLRIに含まれるNext hopにIPv6 のみを受け入れる実装とそうでない(IPv4 も受け入れる)実装がありました。
GoBGPでは最初はコマンドでIPv4 のNext hopを入れてしまっていたため、エラーを返されていました。
経路を広報する際に何らかの方法で Next hop を決める実装をしている場合は、 AFI が IPv4 でもトランスポートプロトコル が IPv6 の場合は IPv6 の Next hop を入れるようにしましょう。
RFC 8950 には SAFI = 128,129 のときにRDを付けるということが書いてあり、 SAFI = 85 のときはどうする？という話もありましたが、その場ではなしで全実装が動いたので、一旦なしで良いと思っています。
Type 1: Interwork Segment Discovery Route (ISD) の Prefix
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Prefix Length (1 octet) |
+-----------------------------------+
| Prefix (variable) |
+-----------------------------------+
ISD の Prefix は明確に Prefix Length (1 octet) と Prefix (variable) と書いてあるのですが、 3GPP 5G の場合は gNodeB の N3 インターフェースのアドレスになるということからか、 /32 固定で実装してしまうことがあります。
書いてある通り、BGPで一般的に使われている Prefix として実装しましょう。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Endpoint Length (1 octet) |
+-----------------------------------+
| Endpoint Address (variable) |
+-----------------------------------+
| Architecture specific Endpoint |
| Identifier (variable) |
+-----------------------------------+
Endpoint Length が BGP でよくある Prefix Length と同等に見えますが、これには Architecture specific Endpoint Identifier (variable) のビット長も含んでいます。
また、 Architecture Type が 3GPP 5G の場合の TEID は下記の通りですが、これも Prefix のように1ビット単位の可変長になっています。
+-----------------------------------+
| TEID (0-4 octets) |
+-----------------------------------+
こちらは複数の実装で、仕様通りに実装できておらず、ExaBGP やGoBGP でもハッカソン の数日前に修正しました。
モバイルネットワークをやっていると TEID も Prefix のように扱って集約できるようにするという発想にならない感じがしますが、経路として扱えば集約できるので、そのように実装しましょう。
SRv6 Data-Plane Visibility
このHackathon は標準化中の SRv6のIPFIXに関するインターネットドラフト を参考に実装を行う会です。
詳しくは IETF 116 Hackathon WikiのSRv6 Data-Plane Visibility を参照してください。
ここでは他社のチームと一緒に行なっており NTTCom の三島さんからのお誘いでBGP-MUP SAFI Implementation and Interop と並行して早坂(@takemioIO )が参加しました。
SRv6 Data-Plane Visibility の結果
成果物がこちらです
https://github.com/watal/ietf116_srv6_data-plane_visibility
このプロジェクトの中では、XDPでSRv6パケットのSRHを受け取りそれをIPFIXに詰める仕組みを実装しようとしました。
XDPの採用理由としてはそもそもこのHackathon はVPPを利用した実装を行うチームがあり、それなら同じパケット高速化の仕組みを持つXDPでも使えるようにしたいな！ということで僕らはXDPの採用に至りました。
チームなので分担して開発を行なっており、自分はこの中でもXDPを利用したSRv6のパケットを受け取ってパースしてユーザーランドに渡す部分の実装を行い実装を完了させました。
ですが最終的な結果としては残念ながら IPFIXのテンプレートの中にSRHの情報を入れて渡す統合の部分が終わらずデモは出来ませんでした。
しかし時間があればできるものだったと思いますので今後も実装を続けていこうと思います！
最後に
BGP-MUP SAFI Team の皆様、相互接続テストを実施していただき大変お世話になりました。
GoBGP、ExaBGPでは相互接続テストを通過させることができ、仕様理解も深まりました。
BGP-MUP SAFI Implementation and Interop の Champion でドラフトの著者の松嶋さんには、
ハッカソン に誘っていただきました。また期間中何度も仕様を確認させていただきました。ありがとうございます。
古河の林さんには、GoBGP、ExaBGPの実装について多くのご指摘をいただきました。
林さんのおかげで期間中に相互接続テストが完了できたと思います。大変感謝しております。
また、NTT Comの三島さん、深川さんには、SRv6 Data-Plane Visibility に誘っていただきました。ありがとうございました。
皆様のおかげで大変良い経験になりました。
SRv6 MUP や SRv6 Data-Plane Visibility 関連の活動は続けていくつもりですので、引き続きよろしくお願いいたします :bow:
Wrap up
