こんにちは。BBSakura Networks株式会社の金井(@masu_mi)です。 遅れてしまいましたがBBSakura Networksアドベントカレンダーの9日目の記事です。
気づいたら学習環境が良くなっていたという話です。また弊社の学習支援の一部についても触れてみます。 はじめに断りますが網羅的な紹介というわけではありません。
弊社ではCisco Modeling Labsの個人ライセンスなどを経費精算できます。 ほかにもUdemyや資格の報奨金などあるようです。 また学習（書籍購入・購読・サブスク加入等）支援制度のまとめページにはこんな一言が書かれています。
誰もダメとは言っていないので、欲しい人が承認を得て精算すれば良い
必要に応じてACM会員やLWNの購読が経費精算できるのは当たり前かも知れませんが心強い一文ですね。
続きを読むこんにちは、BBSakura Networksの山口です。 現在は会社の方針を決め、舵取りをする役割の一部をやらせていただいています。 今日のアドベントカレンダーでは、BBSの現在の働き方とその中でいろいろ試行錯誤してるなかで、最近始めたオフラインWEEKについてご紹介させていただきます。
BBSakura Networks は、ソフトバンクの100％子会社 BBIX と さくらインターネット のジョイントベンチャーで、有線／無線を問わずネットワークをソフトウェアでより便利にしていくために、ネットワーク自体をコントロールする仕組みサービスとして提供させていただいています。
実は2019年に設立した当初から、チームメンバーが全国各地に点在していたこともあり、オンラインを前提にした働き方はなくてはならないものでした。
そんな状況ですので、当初から社員がそんなに集まれないことを前提とした、リモートワークのための仕組み、フロー情報のためのSlackとか、ストック情報のためのGoogle Workspaceとか、Kibelaとか、モニタなどの機材の貸し出しとか、細かいところだと経費精算の仕組みとか、電子契約の仕組みとかもわりとリモートよりに充実していたかと思います。
また、オンラインだけの課題というのも割と早くから経験していたこともあり、その辺りの課題感の共有のために、四半期に1度くらいはみんなで集まって、会社の方針を共有したり、特定のテーマに基づいて議論やワークをして、コミュニケーションを活性化させる場としての全社集会（四半期会議）は比較的早くから整備されていきました。
四半期に1度の全体会議を開催していても、コミュニケーションの質というよりも、種類というべきものが足りないなという実感はありました。オフライン前提で会社に集まって働く働き方しかできなかったときには、当たり前にやっていた、「お互い何の用も無いのだけれども、なんとなく場や空気感・課題感を共有する」ようなすぐには効果が見えないようなコミュニケーションです。新しい発想とか、中長期のズレを補正するとか、アイディアを深めるとかというのは、こういうコミュニケーションから出てくるのかもしれないなというのが私のイメージです。
オンラインだけだと、人的・時間的コストが高くなってしまって、「めんどうくさい」が勝ってしまって、そのうちやらなくなってしまうか進めてくれる人にめちゃくちゃ負荷がかかる、これはなんとかしないといけないと思いました。
BBSでは、今年度からオフラインWEEKという、特定の期間だけ特定の場所に集まって、そこで日々リモートでやっていた業務を、やってみるというイベントをはじめました。 オフラインが当たり前だったころには考えられないことをイベントにしてみたんです。
会社としては、場所とお菓子とドリンクを用意しておく、2回目からはLTの時間が設定されて、お昼ごはんを提供する、グループ会社の人（さくらインターネットの人）も呼んで一緒に働いてもらうというようなことをしました。
おやつコーナーで、なんとなくおやつ食べている人がいて、その周りでいろいろな話が自然に生まれて、何らかの関係性ができていく、仕事上のつながりがない人と関係性を作って行くことが、その先の先の事業や、会社のらしさがつくられていくというような面白い場所にできている気がしておりまして、今後も継続していきたいと思っています。
※さくらのメンバー！
当社はこれからも、リモートを前提とした働き方を推進していきたいと考えています。
もちろんオンとオフそれぞれにメリット・デメリットはあるかと思いますが、リモートを前提することによって、少なくとも居場所を移動できない・したくない人の採用ができ、移動したい人が継続的にチームメンバーでい続けてくれます。通勤時間もなくなるしね。
合わせて、出社したい人は自らの意思で出社できるようにしていくことも合わせて重要だと思っています。オフラインでなければならない業務に従事しているメンバーがいる場合には、特に個別の配慮も必要なケースもあります。 例えばIT大手の富士通では2020年に交通費補助を廃止という ニュース がありました。逆に交通費手当を廃止しない企業、または交通費そのものが給与に含まれているような企業の場合には、出社したい時にすればよいひとと出社しなければならない人で、相対的に不公平感がでちゃうなんてこともあります。非常に細かいことなんですが、当社としてもいずれは考えていかないといけないといけないのかなと思いました。（現在のところ、JVの当社では課題にはあがってきていませんが。）
個人的な感覚では、オフィスはすでに、仕事「だけ」をする場所ではなくなってきていると思います。作業だけならコワーキングスペースや、自宅で集中してするのが当たり前に、オフィスでは、ゆるくつながっているメンバーがいるから、そこでしかできないことを考えて集中的にやる、そのような感じに、当社のオフィスの役割は変化していくのかもしれないな。
月並みですが、メンバーを募集しています！
BBSakuraでは、
シェアードバリューに
世界を変える、Geeks’PlayGround
行動指針に
Move Quick,ChangeFast
Respect and be Respected
Beyond the Border
を掲げており、規範を持って動ける、世界を変えていくようなGeekたちの遊び場にしていきたいと思っています。
ビジネスが継続できるのが大前提ではありますが、新しい仕組みを技術的にも、ビジネスの仕組み的にも作っていける方、これまでの常識に真正面から、時には裏口探して突破できるGeekな方々、ぜひ一緒に面白いネットワークの世界を作っていきませんか？
現時点（2022年12月12日）で採用は、ソフトバンクまたは、さくらインターネットからの出向になっています。ご興味のある方は こちら からご連絡くださいませ！
筆者の DM でもいいですよ！
この記事はBBSakuraNetworksアドベントカレンダー2022の6日目の記事です。
風邪をこじらせて、盛大に遅刻しました！
OCXの開発をしております藤井と申します。
今年の8月に入社しまして、最近はラボとデータセンターに行き来しながら、目まぐるしく、そして楽しく構築作業をしております。
唐突ですが猫が好きです。なので無意味にページの最後に猫の写真を入れてみましたので、是非最後までご覧いただければと思います。
とある日Twitterで、商用IX各社のトラフィックをつぶやいていたら、BBIXの専務取締役兼COO 福智さんに補足され、「DNSが趣味なんですね。一度いろいろお話させてください」とDM頂き、カジュアルにZoomでお話しさせてもらったことから転職が始まりました。
当時、10年ほど同じ会社で働いていたので、他の会社ってどういう働き方をしているんだろうと気になっていたこともあり、またIXというインターネットと密接だけれど、閉域でもあるNWってどうなっているんだろうという興味があり、また面白い仕事ができるのではと応募してみることにしました。
※ IXについて詳しく知りたい方はBBIXとしてもスポンサーしているピアリング戦記という本がおすすめです。
一応お断りですが、福智さんからお声掛けはありましたが、採用自体は通常の採用フローを踏み採用いただきました。
BBSakura Networksの採用は少し特殊でなので少し補足をします。
従業員はBBIX株式会社またはさくらインターネット株式会社どちらかに原籍もっており、兼務または出向という形でお仕事をしております。
私は、お話いただいたのがBBIXなのでそちらの経路での応募をしましたが、どちらの原籍だからといって優遇されるとか、派閥があるとかそういうことは全く無く、フラットな組織になっていて、全員で力を合わせてプロダクトを作って運用しております。
もし、今年のアドベントカレンダーでBBSakura Networksに興味があるけど、どっちで応募しようなど悩んでいるかたがいらっしゃったら、カジュアル面談申し込みがあるので是非ご活用ください。
一言でいうと楽しいです。
というのは、カルチャーフィットしたからかなと思います。
背景として、メンバーは東京在住も多いですが全国各地から働いている方多く、リモートでの勤務が基本となっており、そのためチャットが主なコミュニケーション手段です。
そこでは忌憚のない、しかし思いやりのあるやり取りが日々交わされており。またオンラインだけでなくオフラインのコミュニケーションの場も定期的に開催されております。
BBSakura Networksの行動指針のひとつに「Respect and be Respected」というのがあります。上司・部下関係なく発言や行動ひとつひとつにも、この行動指針が表れていると感じていて、このことが仕事をしていて楽しいと思える一因だと思っています。
まだ、仕事の詳細や成果はここには書けないですが、どこかで発表できたらなと思います。
最初に予告していた猫の写真です。家の近くにいつもいる地域猫です。
余談ですが、BBSakura Networksには猫好きも多く、チャットなどの個人アイコンも猫の画像である人が多いです。
この記事はBBSakuraNetworksアドベントカレンダー2022の3日目の記事です。
こんにちは。BBSakura Networks株式会社の金井です。 5GコアネットワークのOpenAPI定義を調べていた際の課題について少し書きたいと思います。
モバイル網で実用化されている5Gのコアネットワーク(以降、5GC)のAPIのインタフェース定義にはOpenAPIが採用されています。 そのためプロトタイプ実装は容易にできると考えられがちです。しかし実際のところ手軽ではありません。 次の2つが大きな問題としてあります。
これらとは別に循環参照があるとGoでコンパイルが通らない問題があります。今回はこの循環参照について書きたいと思います。
ためしに自作のデバッグツールで仕様ファイル間の依存関係を出力してみます。
あまりに大きな依存グラフなので切り抜きました。完全なグラフはGoogle ドライブに置きキャプションからリンクしています。 理解するのが大変そうですね。
では今回の流れです。
Goは循環依存するパッケージを許可しません。そのため循環参照を持つ仕様ファイルから単純にコード生成するとパッケージ間依存が循環しコンパイルエラーをおこします。
一部のコード生成ツールには外部参照先の定義を埋め込む機能があるため検討しましたが、5GCの定義は巨大で一つにまとめるのは難しいと判断しました。 そのため前処理として5GCの仕様ファイル群から循環参照を取り除いたファイルを作ることにしました。
参照関係だけみると仕様ファイルはこんな感じになっています。これを元にどのような変更を加えたいか確認します。
たとえば次のような参照関係を持つ仕様ファイルはファイルレベルで循環グラフになっています。
スキーマを消してファイルだけ表示してみます。
この循環参照をとりのぞくためにスキーマ定義を移動します。 今回は仕様ファイル間に順序を定めて強制するようにしました。 順序があれば循環は現れません。またアルゴリズムが単純で実装も簡単です。 そして仕様ファイルから決定的な結果が得られます。これは大事な特性です。 もしかしたら焼きなまし法を使えば変更を少なく出来るかもしません。ですが結果が決定的にならないためコード生成には不適切です。
導入した順序にしたがって仕様ファイルに含めるスキーマ定義を決定していきます。 処理中のファイルから後ろのファイルに定義されたスキーマへの参照がある場合は今のファイルへ移動します。 スキーマは内部でさらに別のスキーマへ参照を持っているので再帰的に実行します。
日本語で書くと長いのですがやることは単純です。疑似コードや図を見れば理解できると思います。 次のような擬似コードになります。
func main() { removeCircularRefs(graph) } func removeCircularRefs(graph ファイルのグラフ) { sort.Sort(graph.仕様ファイルたち) for _, current := range graph.仕様ファイルたち { for _, ref := current.使われている参照たち { if ref.To.所属先ファイル が current または ref.To.所属先ファイル.処理済み { continue } 参照先オブジェクトの定義ファイルを更新(ref.To, current) } ファイル.処理済み = true } } func 参照先オブジェクトの定義ファイルを更新(スキーマ, current 仕様ファイル) { スキーマ.所属先ファイル = current for _, ref := range スキーマ.参照しているところ { ref.仕様ファイルないに書かれている文字列 = currentを反映したobjectPathの値 } スキーマ内部にある参照を探していたらcallbackを呼ぶ(スキーマ, func(ref) { if ref.To.所属先ファイル が current または ref.To.所属先ファイル.処理済み { return } 参照先オブジェクトの定義ファイルを更新(ref.To, current) }) }
1つのスキーマ移動に伴う再帰的な変化と参照の変更を図にしました。 右のファイルから処理が進んでいきます。灰色のファイルが処理済みを表しています。
あと細かいことですがスキーマを移動すると元の定義場所が追えなくなるため名前に元の仕様ファイルを示すプレフィックスを付けました。
このヒューリスティックではファイル順序が結果を大きく左右します。 まず素朴にファイル名を使ってみました。この方針を名前ベースと呼ぶことにします。 じつはいろいろなところから使われている ComonData は3GPP TS29.571 に含まれていて後ろ側にあります。 昇順ではうまく行かなそうですね。実際に複雑なグラフになりました。画像にし忘れたのですが降順で実行しても良い結果になりませんでした。 そこでリンクを考慮することにして下のようにファイルの順序関係を比較しました。これをリンク集計ベースとと呼ぶことにします。
func (m ファイル毎のリンク数の集計) Compare(o ファイル毎のリンク数の集計) int { // 1. ファイルに向かってくるエッジが多いと前にくる(先に処理する) if m.外部からの参照数 != o.外部からの参照数 { return -(m.m.外部からの参照数 - o.m.外部からの参照数) } // 2. ファイルから出ていくエッジが少ないと前にくる(先に処理する) if m.FromNum != o.FromNum { return m.外部への参照数 - o.外部への参照数 } // 3. ファイル内部での参照が多いと前にくる(先に処理する) if m.LocalNum != o.LocalNum { return -(m.内部参照数 - o.内部参照数) } return 0 }
リンク集計ベースでは名前ベースよりスキーマ移動を抑えられました。 処理結果を移動したスキーマ数・更新された参照数で比較します。
| 順序 | 移動したスキーマ数 | 更新された参照数 |
|---|---|---|
| ファイル名 | 809 | 17822 |
| エッジ考慮 | 245 | 950 |
どちらの項目も減っていますが、更新された参照数が特に大きく影響を受けています。 これは多く参照されているスキーマを優先して位置を確定できているためだと考えています。 画像で確認するとわかりやすいと思ったので実際に比較してみます。
まず基準となったファイル名による順序です。ファイル名は3GPPの各仕様書のzipに含まれており TSxxyyy_zzzz.yaml という形式を満たしています。
循環参照はなくなっているはずですが参照が錯綜していて読めません。
参照を集計して処理順を決めた実装ではグラフが落ち着きました。
全てのファイルをまとめてスキーマ移動をせず、対象ファイルを小さなグループにわけられれば改善に繋がると考えています。 事前処理として強連結成分分解を使うのが適切で図の上段に対して強連結成分分割をして下段のように分割してから実行します。
まだ強連結成分分解は試していません。まずGoでのコード生成を優先したからです。ところがコード生成は循環参照を取り除いてもまだ失敗します。
いくつか試したコード生成ツールでは事前に確認できていなかった細かい問題が重なりコード生成や生成済みコードのビルドが失敗しています。
また仮に動いたとしても5GCに頻出するoneOf,anyOfの多用されたコードは使い勝手が悪く採用に悩みます。
そのため今の時点ではどのコード生成ツールも採用できないと判断し強連結成分分解の検討はとめています。 (この文を書いてる間にogen-go/ogenはどうかと提案を受けたので試してみます)
おおむねOpenAPIのエコシステムは芳しくありませんでした。 そして生みの親のWeb界隈ではAPI定義にgRPCやGraphQLといった代替技術が採用される傾向があります。 そのためモバイルコア業界からOpenAPIに貢献していかないとエコシステム(少なくともオープンなツール)の大きな改善は望めなそうだと感じています。 エコシステムを絶やさないように貢献し動きやすいモバイル業界にしたいですね。
この記事は BBSakura Networksアドベントカレンダー 2022 の2日目の記事です。
1日目の記事は早坂さんの 勝手にレポート！BBSakura の社員はどんな環境で仕事をしているのか？ でした。
こんにちは。BBSakura Networksのテックリードを担当している日下部( @higebu )です。
普段はモバイルコアを開発しているチームのリーダーをしたり、社内のエンジニアが働きやすくなるような取り組みをやっています。
本日は最近行った GoBGP に BGP Extensions for the Mobile User Plane (MUP) SAFI を実装した話をしようと思います。
ソフトバンク株式会社様のプレスリリース、MECやネットワークスライシングを低コストかつ容易に実現する「SRv6 MUP」の開発に成功 にエンドースメントを出させていただいて以来、SRv6 MUPについて何も表に出しておりませんでしたが、何かをやっていることがお分かりいただけると思います。
※本記事で参照しているインターネットドラフトは下記の通りです。時間が経つと内容が古くなる可能性がありますので、ご了承ください。 - draft-ietf-dmm-srv6-mobile-uplane-22 - draft-mhkk-dmm-srv6mup-architecture-04 - draft-mpmz-bess-mup-safi-01
また、正しくないことを書いていたらご指摘お願いします 🙇
GoBGP とはGo言語で実装されたBGPデーモンで、基本的なアーキテクチャは下記のようになっています。
また、BGPプロトコルを話す部分はライブラリとして公開されており、自身のアプリケーションにBGPプロトコルを扱う機能を足すことができます。
具体的な例として、CiliumでBGPプロトコルのネイティブサポートのためにGoBGPが採用されています。
IETFで標準化中の SRv6 Mobile User Plane(MUP) の アーキテクチャ では、BGPによってMUP Segment情報やセッション情報を変換した経路情報を広報することができると書いてあります。
このときに使うBGPプロトコルの拡張が BGP Extensions for the Mobile User Plane (MUP) SAFI です。
BGP-MUP SAFIの番号は8月にIANAでアサインされていて、番号は 85 です。（Subsequent Address Family Identifiers (SAFI) Parameters）
また、SRv6 MUP Extended Communityの番号も8月にIANAでアサイン済みで、 0x0c となっています。（BGP Transitive Extended Community Types）
これらの番号がアサインされたのを見てGoBGPでの実装を始めました。
後はインターネットドラフトを見てくださいでは後半の話がよくわからないと思いますので、MUP SAFIの構造、4つのRoute TypeとMUP Extended Communityについて簡単に説明します。
BGP-MUP SAFIはBGP-MUPのために新しく定義されたSAFI(Subsequent Address Family Identifiers)です。 また、新しくBGP-MUPのためのNLRI、BGP-MUP NLRIも定義されており、構造は下記の通りになっています。
+-----------------------------------+
| Architecture Type (1 octet) |
+-----------------------------------+
| Route Type (2 octets) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
Architecture Type は今のところ 3gpp-5g のみで、 1 になります。Route Type は下記の4つのTypeがあり、 Route Type specific (variable) には Route Type 毎に違う値が入ります。
+ 1 - Interwork Segment Discovery route;
+ 2 - Direct Segment Discovery route;
+ 3 - Type 1 Session Transformed (ST) route;
+ 4 - Type 2 Session Transformed (ST) route;
Interwork Segment Discovery route(ISD) はInterwork Segment情報を広報するときに使います。Interwork SegmentというのはモバイルネットワークのUプレーンプロトコルとMUP Segmentの間の接続性を提供するMUP Segmentのことです。
構造は下記の通りです。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Prefix Length (1 octet) |
+-----------------------------------+
| Prefix (variable) |
+-----------------------------------+
3gpp-5g ではPrefixはgNodeBのN3インターフェースのPrefixになります。
ドラフトの 3.3.1. Generation of the Interwork Segment Discovery route を見ると、Route Target Extended Communityを付けるのが必須になっており、MP_REACH_NLRIのnexthopアドレスはIPv6でないといけません。
また、Prefix SID Attributeも必須で、AFIがAFI_IPの場合はFunctionを End.M.GTP4.E、 AFIがAFI_IP6の場合はFunctionを End.M.GTP6.E にすることになっています。
Direct Segment Discovery route(DSD)はDirect Segment情報を広報するときに使います。Direct SegmentというのはMUP Segment同士の接続性を提供するMUP Segmentのことです。
構造は下記の通りです。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Address (4 or 16 octets) |
+-----------------------------------+
AddressにはPEのユニークなID（Router IDなど）が入ります。
ドラフトの 3.3.4. Generation of the Direct Segment Discovery route を見ると、Route Target Extended CommunityとMUP Extended Communityが必須になっており、ISD同様、MP_REACH_NLRIのnexthopアドレスはIPv6でないといけません。
MUP Extended CommunityにはDirect Segment Identifierを入れる必要があります。
また、こちらもPrefix SID Attributeが必須で、End.DT4/6、End.DX4/6、End.M.GTP4/6.E辺りが使われそうということになっています。
Type 1 Session Transformed (ST) RouteはMUP-Cが広報する、モバイルネットワーク側のセッション情報を変換した経路情報のうちの1つで、Downlink方向で使う情報が入っており、PEではISDの情報と一緒に使います。
構造は下記の通りです。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Prefix Length (1 octet) |
+-----------------------------------+
| Prefix (variable) |
+-----------------------------------+
| Architecture specific (variable) |
+-----------------------------------+
3gpp-5g ではPrefixはUEのアドレスになります。
また、3.1.3.1. 3gpp-5g Specific BGP Type 1 ST Route に 3gpp-5g のときの Architecture specific (variable) が書いてあり、構造は下記の通りです。
+-----------------------------------+
| TEID (4 octets) |
+-----------------------------------+
| QFI (1 octet) |
+-----------------------------------+
| Endpoint Address Length (1 octet) |
+-----------------------------------+
| Endpoint Address (variable) |
+-----------------------------------+
これはGTPトンネルの情報になっており、Endpoint AddressはgNodeBのN3インターフェースのアドレスになります。SRv6 MUPではこの情報がSRv6パケットのSIDに含まれるArgs.Mob.Sessionに入り、最終的にgNodeB宛てのGTPのパケットのヘッダにエンコーディングされます。
3.3.7. Generation of the Type 1 ST Route を見ると、Route Target Extended Communityを付けるべき（SHOULD）となっており、正しいDirect Segmentにimportされるようにしましょうと書いてあります。
また、nexthopはMUP-Cのアドレスです。
Type 2 Session Transformed (ST) RouteはMUP-Cが広報する、モバイルネットワーク側のセッション情報を変換した経路情報のうちの1つで、Uplink方向で使う情報が入っており、PEではDSDの情報と一緒に使います。
構造は下記の通りです。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Endpoint Length (1 octet) |
+-----------------------------------+
| Endpoint Address (variable) |
+-----------------------------------+
| Architecture specific Endpoint |
| Identifier (variable) |
+-----------------------------------+
Endpoint AddressはUPFのN3インターフェースのアドレスです。
また、3.1.4.1. 3gpp-5g Specific BGP Type 2 ST Route に 3gpp-5g のときの Architecture specific Endpoint Identifier (variable) が書いてあり、構造は下記の通りです。
+-----------------------------------+
| TEID (0-4 octets) |
+-----------------------------------+
このTEIDはコアサイド（UPF側）のTEIDです。
3.3.10. Generation of the Type 2 ST Route を見ると、Route Target Extended Communityが必須になっていて、正しいInterwork Segmentにimportされるようにしなければならないことになっています。
また、MUP Extended Communityも必須で、この経路情報を使うDirect Segmentに対応したDirect Segment Identifierを付けなければなりません。 nexthopはType 1同様、MUP-Cのアドレスです。
※ここからGoBGPのリポジトリへのリンクやコードの説明が出てきますが、 2022/12/02時点の最新のコミット をベースにしています。
使い方は GoBGP のリポジトリ内のドキュメント に記載しているのですが、ここでも簡単に説明します。
まず、下記のように ipv4-mup を有効にしたコンフィグを用意し、gobgpdを起動します。
[global.config]
as = 65000
router-id = "10.0.0.1"
local-address-list = ["10.0.0.1"]
[[neighbors]]
[neighbors.config]
peer-as = 65000
local-as = 65000
neighbor-address = "10.0.0.2"
[[neighbors.afi-safis]]
[neighbors.afi-safis.config]
afi-safi-name = "ipv4-mup"
こうすると ipv4-mup の address familiy が有効になるので、下記のようなコマンドでBGP-MUPの経路をRIBに追加できます。
gobgp global rib add -a ipv4-mup isd 10.0.0.0/24 rd 100:100 prefix 2001:db8:1:1::/64 locator-node-length 24 function-length 16 behavior ENDM_GTP4E rt 10:10 nexthop 2001::2 gobgp global rib add -a ipv4-mup dsd 10.0.0.1 rd 100:100 prefix 2001:db8:1:1::/64 locator-node-length 24 function-length 16 behavior END_DT4 rt 10:10 mup 10:10 nexthop 2001::2 gobgp global rib add -a ipv4-mup t1st 192.168.0.1/32 rd 100:100 rt 10:10 teid 12345 qfi 9 endpoint 10.0.0.1 nexthop 10.0.0.2 gobgp global rib add -a ipv4-mup t2st 10.0.0.1 rd 100:100 rt 10:10 teid 12345 mup 10:10 nexthop 10.0.0.2
ipv6-mup を使いたいときは ipv4-mup の部分を ipv6-mup に置き替えてください。
ドキュメントには 2つのnetnsの中でgobgpdを起動し、経路を広報する例 を載せています。パケットも見ることができるため、こちらを試してみるのがおすすめです。
パケットを見たい場合は開発版のWiresharkが必要です。 こちら からダウンロードしてください。
yuyarinさんのパッチ が入っているためBGP-MUPのパケットをきれいに見ることができます。
ここではGoBGPにBGP-MUPを実装したときに行った下記の点について、それぞれ説明します。 - BGPパケットのパース、生成 - RIBで経路を持ってもらう方法 - APIで経路を扱えるようにする方法 - CLIで経路を操作できるようにする方法 - シナリオテストの追加
BGPパケットのパース、生成に関するコードは全て pkg/packet/bgp にあります。特に1万行以上ある pkg/packet/bgp/bgp.go に多くのコードが集中しているため、ここを読んでいくと大体わかると思いますが、読むのが大変なので、以下にポイントをまとめておきます。
今回は bgp.go に追記が必要な部分以外のBGP-MUP関連のコードをまとめた mup.go を新しく追加しました。
RIBは internal/pkg/table パッケージで管理されていて、この中の table.go と path.go を見るとNLRI毎の処理をしている部分が見つかります。
具体的には func (v Vrf) ToGlobalPath(path Path) error 、 func (p Path) ToGlobal(vrf Vrf) *Path 、 func (t Table) deletePathsByVrf(vrf Vrf) []*Path です。
ここにcaseを足すことで新しいNLRIがRIBに入るようになります。
新しいNLRIをRIBに入れるには上記のみで良さそうに見えますが、実際はコンフィグの neighbors.afi-safis.config.afi-safi-name で新しいAFI/SAFIを指定できるようにしないとテーブルが初期化されず、APIやCLIで経路を投入しても何も起きません。
コンフィグで新しいAFI/SAFIを扱えるようにするには internal/pkg/config/bgp_configs.go の AfiSafiType に新しいAFI/SAFIを追加します。
今回は ipv4-mup と ipv6-mup を追加しました。
GoBGPはAPI定義に Protocol Buffers を使っており、 api ディレクトリにprotoファイルと生成されたGoのソースファイルが置いてあります。
APIを編集したい場合はここのprotoファイルを編集し、コードを生成することになります。
SAFIの番号は enum Safi に、NLRI や Extended Community は api/attribute.proto に定義されています。
コード生成は tools/grpc/genproto.sh でやっており、コマンドは下記のようになります。（これを実行するには事前に protocコマンドのインストール が必要です。）
./tools/grpc/genproto.sh
また、 api/attribute.proto の enum SRv6Behavior を追加したときは go generate ./pkg/packet/bgp を実行し、 pkg/packet/bgp/srbehavior.go と pkg/packet/bgp/srbehavior_string.go を生成し直しておく必要があります。
APIでやり取りするときに使う自動生成されたstructとbgpパッケージ側で使うstructは違うため、相互に詰め替えが必要になります。
この辺りの処理を行う関数は pkg/apiutil パッケージにまとまっており、 func MarshalNLRI(value bgp.AddrPrefixInterface) (*apb.Any, error) と func UnmarshalNLRI(rf bgp.RouteFamily, an *apb.Any) (bgp.AddrPrefixInterface, error) がこれに当たります。Type SwitchでNLRI毎の処理をしているので、新しいNLRIのcaseを追加することで、APIでの経路情報の操作が可能になります。
Extended Communityも同様で、func NewExtendedCommunitiesAttributeFromNative(a bgp.PathAttributeExtendedCommunities) (api.ExtendedCommunitiesAttribute, error) と func unmarshalExComm(a api.ExtendedCommunitiesAttribute) (bgp.PathAttributeExtendedCommunities, error) に新しいExtended Community用の処理を追加する必要があります。
今回追加した MUP Extended Communityをパースするための関数 や、 それぞれのRoute Typeの引数をパースするための関数 を読むと雰囲気がわかると思います。
これらの関数が func parsePath(rf bgp.RouteFamily, args string) (*api.Path, error) という関数から呼ばれることで、追加したコマンドがパースされるようになります。
また、ヘルプメッセージは func modPath(resource string, name, modtype string, args string) error という関数内に書くようになっています。
その他に、経路の表示については cmd/gobgp/neighbor.go にshow系の関数がまとまっていて、こちらも少しコードを追加しています。
cmd/gobgp/common.go にある func checkAddressFamily(def api.Family) (api.Family, error) に使いたい address familiy を書いておかないとCLIがエラーになるところには結構ハマりました。。。
GoBGPではDockerコンテナとしてgobgpdを起動することで、gobgpd同士や他のBGPデーモンとの経路広報のテストをGitHub Actionsで実行するようになっています。
シナリオは test/scenario_test ディレクトリ配下のPythonスクリプトになっており、テストフレームワークとしては nose が使われています。
今回追加したシナリオは mup_test.py です。
setUpClass に書いてある通り、 test/lib/gobgp.py にある GoBGPContainer クラスを使うと簡単にコンテナを作って、ピアの追加をすることができるようになっており、後はテストを書くだけとなっています。便利ですね。
テストの内容は test_02_add_del_mup_route にあり、経路をadd/delしつつ、addしたときに期待した経路が入っているかどうかチェックしています。
テストの実行方法は README に書いてありますが、コンテナをビルドした後にMUPの場合は下記のようなコマンドでテストできます。
PYTHONPATH=./test python3 test/scenario_test/mup_test.py --gobgp-image=gobgp
今のところ、世の中には他にOSSのBGP-MUP実装がないのですが、BGP-MUPに対応したGoBGPはMUP-CやMUP-PEを実装したいときのBGPの部分に使うことができます。
また、本来MUP-CのNorthbound API（未定義）から投入することになっているセッション情報を元にしたType 1 ST Route、Type 2 ST RouteをAPIやCLIから投入することができ、SRv6 MUPの検証が捗るようになります。
今回は、GoBGPに BGP Extensions for the Mobile User Plane (MUP) SAFI を実装した話について紹介させていただきました。
BBSakura NetworksではこのようにIETFで標準化中の新しい技術を使った業務を普段から行っており、BGPやSRv6等のネットワーク技術に明るく、3GPPの仕様が読めて、プログラミングもできる仲間を募集しています。
気になった方は 採用情報 からご連絡ください。
よろしくお願いいたします。
この記事はBBSakura Networksアドベントカレンダー 2022の1日目の記事です。
前回のBBSakura Networksアドベントカレンダー 2019を見たい方はこちら
こんにちは、BBSakura Networks モバイルコア開発チームの早坂です！
BBSakura Networksができて今年で三年目、三年前と比べると随分と我々もチームメンバーが増えましたがまだまだ我々の目指すいろんなものがつながり合う世界には程遠くその世界にたどり着くために日夜開発を頑張っています。
また、我々は基本的は会社全体としてフルリモートで働いていて北は北海道、南は大阪や京都という日本全国で弊社のメンバーが働いています。
そんな中、とあるところから聞こえてきたのが
「どんな働き方やどんな人がいるのか少し謎に包まれてる会社だよね」
「BBSakuraに転職する際に全然情報がなくて困った(´;ω;`)ﾌﾞﾜｯ」
と言う声が...そこでBBSakura社員にアンケート取材を行い、BBSakura社員の仕事の環境をネタにした本記事を執筆をしました。
今回の記事のテーマは
社員はどんなキーボードやマウスを使っているのか！！！
みなさまは入出力機器にこだわりをお持ちですか！？
自分の使いやすいキーボードやマウス、目の疲れにくいディスプレイなどなど… 弊社は入出力機器の持ち込み利用は自由になっていますので人によっては大変こだわりも強く、BBSにはどんな人たちがいるかが透けて見えるのではないか！？と思いこのテーマにしました。
そんな弊社社員の机事情を北から南に向けて写真とともにお届けしたいと思います。お楽しみに！
ここからは北海道在住の会社のメンバーの机をご紹介します！
小樽在住の30代後半の男性、テックリードの作業場の風景です。プログラマーの机感を感じます！
以下に机のものをご紹介します！
さくらインターネットから出向しているのでPCはさくらインターネットから貸与されたPCを使ってます。
iPadはBBSakura支給のもので、3GPPとか弊社で全員が読み放題になってるオライリーのeBookを読むときに便利に使っているとのことです。
こだわりはマイクで
リモート会議では音質が大事だが、自分があまりハキハキしゃべらない人なので、マイクでカバーしようとしている
とのことだそうです。
ディスプレイにかかってるのはお子さんからの父の日でもらったプレゼントのようです！かわいいですね〜💕
続いては小樽在住の30代前半の女性、モバイルコア開発チームのエンジニアの作業場です。（よく見るとCiscoのスイッチが置いてたりしてて気になる作業場...!）
先ほどのその1で書いたテックリードとご夫婦で開発に取り組まれてます。
写真にうつっている弧状のものはスタンドライトだったり、大変こだわりを感じますが特にファシリティにもこだわってるらしく、
LANケーブルはコンセントから壁に入って"ネットワーク機器とか置いてる棚"に、HDMIケーブルもおなじく壁内を通って壁掛けしているテレビにつながってます
とのことでした。ここ以外にもネットワーク機器があるなんてエンジニアとしてはワクワクしちゃいますね！
ちなみにネットワーク機器周辺の写真はこちら
Ubiquitiをメインにしたネットワークになってて素晴らしいですね✨！自分も欲しい....(いいなー
石狩在住の40代前半の男性、モバイルコア開発チームのエンジニアの作業場です。二枚の4Kディスプレイなのがかっこいいですね！
この方はさくらのセキュアモバイルコネクトの運用もやられているので、「ラズパイ＋ LTE モジュール」は通信テストで使用しているみたいです。
こだわりポイントはクラムシェルモードで利用して、それでいてキーボード類は純正のApple製品を使ってるので純粋なMacのデスクトップ環境を作ってるのがポイントみたいです！大変気合が入ってますね...!(なおカメラの消し忘れに怯えることになるのが辛いところらしい)
ちなみに人形は娘さんが置いたものらしく、朝放送してる某有名キャラクターが映ってて家族の中の良さを感じますね〜！
ここからは東北から関東にかけてのメンバーの机（作業場）を紹介していきます。
仙台在住の20代前半男性、OCX開発チームのエンジニアの作業場です。質実剛健な感じがいいですね！
彼のこだわりポイントはこの3つらしいです！ - マウスは軽めのを選ぶ - 必ずなにかしらの甘いお菓子を置いてる - ESCキートップをさくら仕様にしていること
(これは）たしか入社式でもらった物のはず
このさくらインターネットのロゴつきキートップはさくらインターネットへの新卒入社特典のようです！
栃木県在住の30代前半男性、OCX開発チームのエンジニアの作業場です。
主にOCXのクラウド接続まわりの仕組みを作ってるネットワークエンジニア、Go勉強中のこと。
こだわりポイントはいろんなところにあるようですが、（キーボードもよくみると光ってる）特に机の空間をうまく使うための立体設計を含めた位置関係だそうです！
タテヨコ約1mの机を広々使うため、スタンド(写真左奥)を使って立体的に物を置けるようにしてる。上段にはiPadや領収書管理用クリアファイル、中段には文房具、下段にはノートを置いてる。ノートはmaruman N181A、めっちゃおすすめ。コップの位置も色々試して腕と腕の間に落ち着きました。
ディスプレイの付箋はもしやTODOリストなのかと思いきや、
ディスプレイ左下には忘れちゃいけない言葉を貼ってます、「良い仕事にしようと最初から思うな」などなど書いて貼って自分に言い聞かせてますｗ
とても熱いエンジニアということが伝わってきますね！
つくば在住の30代後半の男性、モバイルコア開発チームのエンジニアの作業場です。
filco使いなのでこだわりがあるのかと思いきや、US配置の軽めのメカニカルなら何でも大丈夫とのこと。最近はマウスをトラックボールに変えたいとか。
ちなみに（机で写されてはないですが）
本棚に戻さないからどんどん机の右側が溢れていってます
会社だと綺麗にしろと言われて渋々片付けることになりますが、自宅だとうっかりテトリスのように山のようになりがちですよね😇
東京在住の30代後半の男性、モバイルコア開発チームのエンジニアの作業場です。
最近はGoでの開発を勉強中のこと
お家でノマドワーカーをしているのがこだわりみたいです。カフェテーブルでお仕事してるのはとてもオシャレで素敵ですね〜いわくセキュリティには気をつけてるのこと。
壁紙をよく見ると描かれてる3GPPチックな絵柄がキラッと光りますね！
東京在住の30代前半の男性、OCX開発チームのエンジニアの作業場です。
社内でDNSに詳しいエンジニアといえば彼なのですごく頼もしいです。
机周辺にチラッと見えるキムワイプやマイク設備やSwitchがオタクとしての信頼性が高くて日々の生活がここで行われていることがわかっていいなーと思います！
横浜在住の40代前半の男性、我らがCMOの作業場です。
実はBBSakuraではリモート勤務の都合上会社からディスプレイやモニターアームを貸与しています。入社したらちゃんと会社のような環境を構築することが可能です！
よく見るとDATA-EX賞 データ社会推進 功労者賞のトロフィーがあってかっこいいですね！
千葉在住の40代前半の男性、我らがCEOの作業場です。
右にチラッと見える印刷機が自宅がオフィスって感じになってるのが伝わるいい写真だなーと思います。
ところで人間の腕は2本なんですが、キーボードが二枚あるのは一体どういうことなのでしょうね...
ここからは関西在住のメンバーの机（作業場）を紹介していきます。
京都在住の20代後半の男性、OCX開発チームリーダーのエンジニアの作業場です。
ここにもシルフィーユーザーが！マウスパッドのロックマンがかわいいですね〜！
続いては自分です。こちらは京都在住の20代前半の男性、モバイルコア開発チームのエンジニアの作業場です。
最近はGoとかCを書いたりしてます！
5k2kのディスプレイをコードを書くのに使い、そしてサブの4kディスプレイ縦おきを3GPPのTSを読むのに使っています ただサブはTwitter専用ディスプレイになることもしばしばです 😇
こだわりポイントは、Thinkpadのキーボードをわざわざ古いものを使ってる点です！ Thinkpadのキーボードは実はT410と互換なのでそれを使えば換装可能でUS,JIS,UKなどに変更できます。なので大学からこれを愛用して生活してます！
兵庫在住の40代後半の男性、モバイルコア開発チームのエンジニアの作業場です。
3GPPを読んでいたり、モバイルに関する本が積み上がっていてまさにモバイル開発のプロって感じですね！
ここでも会社貸与での4Kディスプレイを使ってる人がいるので買わずとも自宅設備を整えれるのは嬉しいですね〜
こちらは兵庫在住の30代前半の男性、BBIXのシステム開発エンジニアの作業場です。
最近はNext.jsとかGoでアプリを作る人をやっているとのこと。
大変入力デバイス周辺にこだわりを感じますね！
本人曰くもこだわりは分離キーボードと万年筆とのこと。ちなみに万年筆のインクは青墨が推しらしいです！
弊社社員には実は海外の拠点で活躍されてる方もいらっしゃいます。今回はそちらの一枚もお願いして記事にしました。
シンガポール在住の40代前半の男性、BBIX Singaporeの成長にかかる諸々を取り組んでいるエンジニアです！
Weworkがシンガポールにもあるのでそこで普段は働いているみたいです。BBIX Singapore に関しての発展が楽しみですね！
仕事場レポートいかがでしたでしょうか！みんなに机の写真をくれ！頼む！とSlackでお願いしまくったところ、
机周辺を片付けないといけないのがつらい😭
出すのが恥ずかしい...🥺
みたいな反応が来てなかなか集まらなくて大変でした...🥺🥺🥺 写真にご協力してくださった会社の人たちにはこの場を借りて御礼申し上げます。
個人的な感想はキーボード結構みんなこだわってるなーというのが衝撃的でした。割とみんな分離キーボードじゃん・・・というのがびっくりです（なお、自分は分離キーボード慣れなくて自作したけど結局Thinkpadキーボードに戻ってしまいました・・・😇）
記事を振り返るとかなり個性豊かでこだわりを感じられる机（仕事場）だったのではないかなーと思います。本当はもっと近くで見させて貰えばキーボードのすり減りから打鍵の癖とか面白いものがわかったのかも...とは思いましたので、他の社員が増えた時や趣味趣向をもっと集めてみて記事にしても面白いなーと思いました。
とはいえ自宅だからこそノビノビとした環境でやれていることが伝わる記事なのではないかと思います。BBSってどんなところなのかなと気になる人への一助になればと嬉しいです。
以上、お付き合い頂きありがとうございました！
改めまして、こんにちは。BBSakura Networksの夏(@xia)です。
この記事はBBSakura Networkのアドベントカレンダー 23日目です！
多分中国テクノロジーに関する様々な記事があると思いますが、ここでは自分の経験とそれの感想について書きたいと思います。
私は高校卒業後、来日し今でも年１回や２回中国に帰ります。こんな頻度で帰国しても、その度に、「エッ、また進化したの！」と思ってしまいます。
先月、中国のお店で会計する際に、店員さんに当たり前な感じで「支払い方法はアリペイ、それともwechat payですか?」と聞かれました。現金しか持ってない私は「あっ、、現金です」と回答したら、まるで田舎から来た娘と見られてしまいました。
スーパーで買い物した最後、店員さんに会計してもらおうと思ったのに、弟は「先ほど箱に入れたものを全部自分でスマホでスキャンしてたので、既にスマホで自動会計済で、あとは店員さんがそのリストと買った商品を確認するだけでいいよ」と言ったら、「エッ、また進化した」としか言えないです。
中国の街ではユニフォームを着てる出前の配達員をよく見ます。
出前デリバリーサービスが普及されてる為、ランチタイムには、ほとんどの方は出前を注文し、ほぼ30分以内指定場所に届けられます。iiMedia Researchのデータにより、2018年の中国の出前注文するユーザーの規模は2017年と比較して17.4％増加し、3億5800万人に達し、2019年には4億人を超え、その成長率はまたまた続くと言われています。
そのアプリ機能は主に
・注文・評価機能
・オンライン会計機能
・配達員居場所がリアルタイムで確認機能(GIS)
ぐらいだと思う方が多いかもしれませんが、実際にはそれだけではありません。
これはとある出前注文アプリの操作画面です。出前注文アプリなのに、ホテル予約、タクシー呼ぶ、映画館チケット予約、医療方面、様々なサービスも含めています。また、デリバリー内容は出前だけではなくて、欲しいもをデリバリーのお兄さんに頼めば、ほとんど届けてくれます。近年、夜間に胃薬や風邪薬など非処方せん薬を買えるようなサービスも出てきました。
中国では、デリバリーお兄さんが「世の中で届けられないものはほとんどない」とよくに言われています。
本当に便利です、もし中国へ行く機会があれば、ぜひそのサービスを体験してみてください。
Wechatは中国版Lineです。中国では日常生活に欠かせないアプリだと思います。
この前、中国ホテルを予約しましたが、色々リクエストがあるため、相手のwechatを追加しました。店員さんがほぼ２４時間対応してくれて、現地の写真や天気情報は全てwechat経由で提供してくれました。中国ではビジネスの場合でも、wechatでコミュニケーションするのは主流です。日本で電話かメールしか問い合わせできないことと比較して、それに本当に感動しました。
もちろん、チャット機能以外、水道光熱費用、会社保険支払い、携帯・インターネットなど費用チャージなど、様さまなオンライン会計サービスを提供しています。
第三者提供されるサービス、タクシー呼ぶアプリ、デリバリーアプリ、オンラインショッピングアプリもwechatと連携して利用できます。saasを提供されている為、技術者が簡単にアプリを開発するのもできます。
一方人口が多い中国では、病院の予約は社会問題です。wechatはそれに対して、2016年からオンライン病院予約サービスを提供始めます。携帯の位置によって、そのシティーの病院や地域保健サービスセンターの情報を提供し、オンライン予約、電子診療情報作成、オンライン問診など、様々なサービスを提供します。
自分もその機能を試してやってみました。
元々中国の11月11日は「光棍節（こうこんせつ）」と呼ばれており、日付の１人を連想させる「１」が並ぶことから一般的に独身の日という意味合いが広まりました。
2009年、そこに目をつけたアリババは、同年11月11日に中国でECサイトの大規模な販促イベントを開催。
今年はちょうど独身の日セール開催の１０年目です。わずか１分間で1000億円、一日５兆円売上達成しました。また記録を更新しました。
なぜこんな大量のデータのやり取りができるでしょうか？サーバーの冷却処理は大丈夫でしょうか？
アリババ自社開発の液浸冷却や浸水空冷をはじめとするグリーンテクノロジーにより、Eコマース取引1万件あたりの電力消費量を2kWhまで低減しました。これにより「天猫ダブルイレブン」のデータセンター全体の消費電力量を昨年から70%削減して20万kWh以上の省電力を実現したそうです。
では、なぜ常に進化していますか？
政府の協力と技術の発展はもちろんですが、私は失敗を恐れず、チャンスとスピードが優先は最も大きな理由だと思います。
中国IT産業は世界の最先端で走ってるとよく言われていますが、この２０年の発展を振り返ってみると、順調とわ言えないです。例えば、シェア自転車事業の初期段階で、大量遺失や路上放棄と言った社会問題、ネット通販でも消費者損壊事項が数多く発生したなど、様々で問題が発生してしまいました。
「昨日より今日はよくなる」、これは中国でよく言われてる言葉です。あらゆる規制や障害に挑戦しながら、試行錯誤を繰り返して、その結果は現在どんどん便利になってる生活だろう。
その繰り返しの結果で、50代のお母さんはDiDiでタクシーを呼ぶのは常識だと思い、街の豆腐屋さんでもQRコードで決済するのは当たり前なことで、飲食店でマシンでセルフ注文、セルフ会計は普通なことで、携帯さえあれば、なんでもできちゃう生活になってきます。
年末にはまた中国に帰りますが、次の進化、楽しみしています^^
