テストOFが信頼できなかったので、多ポートのあるLinuxはことか持ってきて頑張った。入ってたけど、今はベンダの世界に任せる状態。迷走しているなというようなところもあるけど...そこまでもう影響力発揮できない。仕事ではないと考えていると思う。BSNはプロトコル部分の標準化に時間かかるの待ってられないのでベアメタル戦略に変えてる。エージェントとコントローラの通信は自分でスペック決めて早く動かせる。標準化の難しさを表していると思う。OF仕様のオプションになってるところ、バージョンアップも差分的に変わってる。「バージョンいくつ対応」といってるけど対応していないように見えるところがある。それをどう使いこなせばいいんだろうとか、使いこなしの勘所とかあったりするのでしょうか?ないです。オープンで単一のI/Fと言っていたけど、スイッチごとにCapability違う。用のチップ作ってる会社がある。それがでてくると、インタフェースがシンプルになって中のインプリをうまくスケールするように...。なればコントローラはシンプルにできるんじゃ。いうのが出てこないと難しいかなと。ハード触らずにソフトだけにして、思い通りにコントロールできる方向にした。ハードが出ないと、当初イメージしていたPureでシンプルな世界の実現は難しいのかな。OFの情報、どこに何があるのかわからないことが。Extensionの追加、EXT-No.とか。出たか、とかその提案とか。ONFなので参加企業だけ。ONF内部的にはあるかもしれないけど。はいま500個くらい公開されてる。組み合わせて複雑なパケット処理。USではNW研究によくつかわれている。routerGUIツールでコンフィグ自動生成vNODEプロジェクト、仮想化基盤にClickを利用。自動配置・実行させる。FLAREというスイッチを開発。ものを最近は開発している。100Mフローでもいける。openflowを制御QAclick学生向け教育って結構大変じゃない?学生にもよるけど、かかる人だと1か月2か月とか。NWの知識があればそんなにかからない...エレメントの理解ができれば。Flareを個人で使いたいと思ったらどうしたらいい?お金があれば...。無理であれば、共同研究とかそういう形でやれればFlare貸出とかできるかも。いまそういう形で企業数社と話を進めていたりする。興味あれば中尾先生にコンタクトを。NWデバイス、FDBとかの実装ってどうする?共有メモリや個別のメモリ空間もあるのでその辺を使って。16-32GB位までの目盛がボードにある。NPはひとつのLinuxとして見える。BoxでAP作って仮想化するというのをやっている。インダストリに入らない理由とかがある?事例はあるらしいが私もよく知らない。Boxとかそういうのあはる。専用のチップがあったからあまりやらなかったんだろうけど、これからNFVとか汎用チップで実装していく方向に進むと広がるのでは。CPUに上がる?パケットはNP側から転送、そこもClickモジュールつくって、NICのように見えるようにエレメントを作っている。Intel側でapacheとか動かしておいて、そっちに処理を振るとかそういうこともやれる。実行時にパケット流しながら指示を入れて反応見るとかできる?ダイナミックな変更は無理か。中のパラメタとかは書き換えることはできる。リアルタイムにできると面白いなと。Ricart)(ゲストのところはメモちゃんと取れてません...。pythonpica8大くんのSDN開発話|NCLC今日の内容TremaEdgeのつかいかた。したものをつかっています。github.com/proshiba/trema-edge今日のゴールTremaEdgeでL2SWをつくるついでにパケット精製、WebAPIの定義、DB操作といったフレームワークやライブラリを紹介。集中コントローラフローテーブルv1はデバイスについてひとつ。match-actionv1.3では複数テーブル。複数テーブルを扱う[テーブル間の連携]ためにインストラクションというフィールドが増えた。match-instructionスイッチでは何ができるのか。宣伝(pica8)L2/L3とOpenFlow両方対応している。OF1.0/1.3で接続テスト済みCrossFlowテーブルミスした場合にL2/L3の機能で処理をすることができる。必要なところでだけOFのルールを入れることができる。今年9月くらいのバージョンで。OF仕様を逸脱?順序は固定。OF仕様とは異なる動き。OFで実現できないからL2/L3というわけではない。OFCでやることもできるけど、全部をコントローラで作るのは大変。ある程度既存のL2/L3に任せていいのであれば任せてしまってよいのでは、というのがコンセプト。したらL2/L3に渡すというのがつけられるのかもしれないけど、いまのCrossFlowでは全然別の機能。単純にフローエントリに対してマッチミスがあった場合にL2/L3にわたす。pica8すべての製品で実装?Broadcomのスイッチでも似たようなのがあったと思うけど。全部のスイッチでできるわけではない。いれたとしてもL2/L3としてちゃんと動くように実装されてる製品はあまりない。板橋さん、玉川さん)OpenFlowの実用実験2010-2011あたりから技術動向調査とかやってる。技術習得したい社内ネットワークを一部借りてテストベッドをやろう。自生して技術を、と思うけど、開発周りの話になると弱いのでどうしようかな。サンプルベースにカスタマイズしながら学習しようどうせやるならうまく社内の環境とつながるような。最低でもL3でやりたいよね。コアのL3SWは評価用にいろいろ買った。安価なPica8の機材でやろう。万が一で、L2/L3としても使えるというのもあり。冗長化、というながれで。いま移転直後で止まっちゃってる...将来的にはもうちょっと侵食していきたい。L2スイッチとして実装。ブリッジ相当の機能がちゃんと動くか。L3スイッチとして動くかどうか。L3の方へ移行させちゃいたい。日本語ドキュメント、サンプルコードや情報が多い。PCの上に仮想サーバおいてやってる。テストできたら実験環境へ。Tremaは随時アップデートしてなるべく新しいバージョンで。agentアドレス書き換えUDPのチェックサム再計算とかの実装。VLANこれはそんなに難しくない。TAGの扱いが違うところがあった。接続があるところをどうするか。OFSは2台1組として優先度を設定。優先度の高いものをActive/もう片方はポートダウン。優先度が高い方が仮想IP・MACの処理コントローラから見てスイッチからの接続が切れた場合に優先度を再評価。L2冗長によるポートダウン検出などを併用して。切り替わりにかかる時間とかも。運用コントローラ、コードのメンテとかをどうするか全フロア適用すると10倍近いノードがぶら下がる。負荷とかどうなるか?OF1.3対応考えないと。Q&A情シス部門との調整、説得ってどうやったの?トップダウン。やりたいことを経営層に先に承認もらった。情シスが従わなければいけない状況を作った。経営層の口説き落とし方を...当時、SDN/OpenFlowってバズってた。上が非常に興味を持っていた。会社くっついてインフラ刷新したときに、OpenFlowとか意識した選定をせよという指示もあり、経営層がそういうマインドを持っていたので、割と通りやすい状況だった。エンジニア側の思いに対してもともと理解があって前向きに判断してもらえた。裏は少数精鋭、3〜4人くらい。経営層が協力的......、「一部の領域に入れた」というのは、経営層が使ってるNWも含めてデプロイしている。メンテナンス、運用やトラブルシューティング、それらの引き継ぎやトランスファーってどうしてる?現状策がないというのが正直なところ。ある程度開発者がバックアップしながらやれることを渡していく。マニュアルの話なのかオペレーション一緒にやるのか、形としてはいろいろあるけど、少しずつ移行。実際デプロイして機器つないだ環境でのテスト。テストコードってパケットパターン作ってチェック。現実ではいろんな機器つなぐと予想外の動きが。テストやデバッグどうしたんだろう?開発環境では、プログラム使用に関するテスト。テストベッドでは社内の様々なノードに対してPing等の津新流して実際回るかどうか、一般的なネットワーク構築時のテストを一通りやってる。実環境で動かしたときのトラブルとか事象とかってどういうところ?L2冗長化、ポートステータス通知とかの応用で考えたんだけど、やってみたら必ずしも通知が来ないことが。コード公開する予定ってあったりする?今のところないけど検討します。そのほかTremaEdge上への移植もやってるけど、結構大変だった。APIの変更や機能的に足りないところとか。目標は4-5行でリレー実装できるようなものを。興味があれば使ってください。実装作った後にその辺が公開された。早く出てくれれば...。自分で解析するルーチン書いてパケット構築する実装もしたりしてた。