# P4ユーザー会

CTC参加者：
基盤１　渡部、栂崎
基盤３　本

元CTC参加者（笑)：
Intel 小鮒さん
Cisco 浅井さん
Juniper 有村さん

Twitter Hashtag #p4usersjp

## キャリアにおけるP4ユースケースの紹介
NTTNS研　武井　勇樹

- ユースケース
-- ネットワークの可視化(Inbound-telemetory)
-- C/D分離
-- 装置のスケールアウトの簡素化

- Stratum ProjectにもNTTとして参加している
ONFがやっているOSS
https://www.opennetworking.org/stratum/?utm_referrer=https%3A%2F%2Fwww.google.com%2F


- stratum（日本語）
https://www.publickey1.jp/blog/18/grpcstratumonfgoogle.html

>
> [name=aTogasaki]stratumについて去年の武井さんのスライド発見しました。
> https://mpls.jp/2018/presentations/MPLS-JAPAN2018-takei.pdf

### Inbound-Telemetoryの広域化
キャリア網において全ての装置をP4にするのは現実的ではないので、
非対応装置を考慮した実装が必要

- INT対応装置でINT非対応装置で挟む
- SW1(INT) <-> SW2(INT) <-> router(非INT) <-> 遅延用サーバ(非INT) <-> SW3(INT)
- INT対象の識別にはProbeMarkerをしよう。TCP/UDPヘッダの直後に挿入
- 各スイッチのタイムスタンプ情報からスイッチ感の遅延時間を算出
- Timestamp同期のためにNOSでNTP同期(msecが限界)
> [name=Tomoya Watanabe]INT対応装置のみであれば、nsオーダーで遅延表示ができる
- Grafanaというツールで遅延の可視化をしている(Kibanaの友達)
https://qiita.com/Chanmoro/items/a23f0408f0e64658a775

> [name=aTogasakii]INTとオフロードがよくわからなかったです
>>[name=Tomoya Watanabe]In-bound Telemetryは、通常Telemetryとか通信の可視化系のものはManagementとかで統計情報を集約したり、通信のメタ情報を集約サーバに送って解析するっていうのが今までのやり方。
>> In-boundになると、P4で可視化のメタ情報の埋め込み（Timestamp)とか、送信したいヘッダとかを定義してあげてそのままIn-boundのパケットをポートミラーリングで出してあげたりできるので、性能とか遅延の観点で色々向上する。今でもそういうのはあるけど、NW装置と別装置を持ってTAPしたりしてやったりするけど、それが１装置でできるようになる（理想、実際は多分性能的に無理）
>>
>> オフロードはvLNSのC/D分離と完全に同じ

### P4実装内容
- 中継するL2スイッチにデータの格納/参照を実施
- パケットの識別には5tupleをしよう
- 上り通信受診時に、sourceMAC,sourceportを保持

### DB格納情報
sourceIP,dstIP,proto number,portNumber,MacAddress,port,timestamp

### 動作確認
仮想化環境ではパケットの送信着信までは確認済み。
実機ではまだ確認できていない。実装済みではある。

## キャリアからみた期待
- P4言語への期待、可能性
-- ハードウェアを活用した様々なユースケースがある
-- DCだけでなくどこでも普及する可能性
-- 技術的にはそんなに難しくない
-- 各社が対応を発表している、OSSもある

- P4の課題
-- HW依存が結構ある。複雑な開発なスキルが必要
-- 開発、保守の体制がまだ整っていない

# P4テストベッドについて
NICT 石井秀治

Openflowの研究開発やテストベッドを作っていた人
> [name=aTogasakii]テストベッド：商用を模した検証環境
> OpenFlow：https://www.infraexpert.com/study/sdn02.html
> juniper contrailとかは違う？
>> [name=Tomoya Watanabe]違う。contrailとかはIPとかVxLANを使って動かしてるけど、OpenflowはそもそもOpenflowっていう独自のプロトコルになる。完全なる失敗作。
>> >[name=aTogasakii]なるほど。
>>
>>個人的な見解だけど、コントロールプレーンとデータプレーンを分離して、コントロールプレーンをProgramablleにしましょうという思想自体はあってた。だけど、そのために既存の装置をすべてOpenflow装置に変更したり、NW設計の考え方を変える必要があったことが非現実的だった。
>>
>>実際、上記の思想は今も残っていて、NSOは完全にその考え方を踏襲している。NSOの良いところは、既存のNW設計の考え方を一切変えないし、装置の変更も必要なしで上記のSDN的考え方だけ持ってこれたのが成功の要因だと思う。
>>>[name=aTogasakii]既存環境を全て変える必要があるのは確かに難しいですね。NSOの実機はそのままでWrapする考え方も面白いですよね。
>>[name=aTogasaki]OpenFlowとかと違って、p4はその装置内に閉じた話なのでNWの中で部分使いができるというイメージであってますか
>>>[name=Tomoya Watanabe]近い。部分使いもそうだし、今のプロトコルを変更することない。
>>>

Openflowの経験を活かして、P4テストベッドを作ったという話。
というよりも、今から作る？という話かもしれない。
すでに作っているOpenflow testbedを流用して作るというイメージ。

# GTP/SRv6 stateless translation

Toyota 李さん

Packet sizeとThroughputを調整した上で、性能試験をしたという話。

# Intel FPGA PAC N3000を P4のNETCOPE P4コンパイラーの使用事例

小柳さん

Barefootを買ったけど、FPGA PACの話。
今、２つのソリューションがある。
- Programable NIC PAC N3000
- Programable Switch Barefoot

目指すところは5GのAccessのあたり。
今まで、実はFPGAのNICは結構出てきているが、メジャーにはなっていないのが実情。
理由としては、特別な扱いをしなければいけない板なので、サーバーベンダーから買うことができないとか色々あった。

コンセプトとしてはOpenな状況で使えるというコンセプトになっている。各ベンダーからOEMみたいな形で出せるというコンセプト。

## FPGA PAC N3000
QSFP+/28 x 2 10/25GbE

今まではFPGAを書く場合はHDLを使う必要があったが、P4コンパイラがあればP4で書くことができる。

BarefootのSwitchとサーバー側で同一のP4ソフトウェアを使うことができるので、HDLを使わなくてもすむかもしれない。

## 事例
楽天モバイルでvRANのEdge Cloudで「BBUをソフトウェアで仮想化し、x86サーバをエッジサーバとして配置する」ここで用いられているのがIntelのFPGAカードがPAC N3000となっている。なので、既にDeployはされている

## NETCOPE P4コンパイラについて
マクニカ　アルティマカンパニー　清水さん

## NETCOPE社概要
- 本社：チェコ（！）
- メイン製品：FPGA用P4コンパイラ
- パートナー：イギリス、ドイツ、日本（マクニカアルティマ）

## FPGA + P4で実現する主要分野

ISP
- 仮想GWの高速化 vBNG,vEPC,S/PGW
-- パケットヘッダ変更、大規模テーブル検索、QoS,統計カウンタ

DC
- 仮想機能のオフロード化

## 出力形式
- Bitstream
-- P4コードを記述
-- NETCOPEのクラウドにアップロード
-- 生成されたBitStreamを焼き込む

- Netlist
-- ちょっとよくわからなかった

## 実際のプログラミング方法

P4でテーブル定義などを実施（この状態ではテーブルは空）
AtomのAPIを用いて対象とActionを投入していく
Atomを通したりBypassしたりとかも定義可能。（ブロック図がよくわからなかった）

## 評価環境

Linuxで生成したパケットを40G転送してFPGAでLoopbackしたものをWIRESHARKで確認。TRexで処理の内容を確認。
- TRex
https://trex-tgn.cisco.com/

## ユースケース

SRとP4

- Encap
- GTP/UDPのDecap後のEncap

## Summary

- ラインレートで低ジッタの処理を実現できるので５G時代の多様なパケット処理に最適
- NETCOPEのコンパイラで、HDLなしでできる
- マクニカでP4およびFPGAをワンストップで提供可能

## QA

LINEのしろくらさん

- Linuxで使えるか？　使える
- 送り返すことはできるか？ Netlistを使ってHDLがかければいける
>[name=Tomoya Watanabe]Bitstreamはまだ完全ではなく、簡単なユースケースであればP4でいけるが、やはり細かいところはHDLでやらなければいけない。NETCOPEのRoadmap次第。P4で完全に書けるようになれば、HWベンダーの組み込み系のエンジニアからレイヤーが１個あがるのでSIerで普通にNW装置が作れるようになるとおもう・・・が、普通にHWベンダーがP4で作る未来になって終わるかもしれない。わからん。
>

誰か
- 楽天モバイルはP4?　違うwHDLでやってる。詳しくは言えないがRANの部分で使っている。

NICT 石井さん

- ２つ絵があったけど何？　10Gx8と4*25Gの両方モードがある。オーダーするときに選ぶ。
- HDLはしんどいので、P4でかけるようになると嬉しい。 これはNETCOPEのRoadmap次第なので、NETCOPE頑張れ！

# CiscoにおけるP4の活用と展望

佐藤哲大

## P4でネットワークデザインが変わるかもしれない

今まではASICありきのNWを作っていた
今後は、NW要件に応じてASICを作っていく時代？

固定ASICからプログラマブルスイッチになることによって、HWリソース（StaticにAllocateされているメモリ等）の制約も柔軟になる。

## Ciscoのラインナップとして

Nexus 3400シリーズにBarefoot Tofinoがのっている
- 34180YC
- 3464C

## 開発環境とDeployについて
DaPIPE使ってP4を作る
https://www.opennetworking.org/wp-content/uploads/2018/12/daPIPE.pdf

## QA

えびさわさん
- DaPIPEは使えるの？　まだプロトタイプ的なニュアンスが強い

# Arista 7170紹介とデモンストレーション

土屋さん

## ラインナップ

- 7050X3
-- Trident-3
- 7160
-- Cavium zxp80
- 7170
-- Barefoot Tofino

## Targetアプリケーション

- ネットワークセキュリティ
- 大規模なNAT
- 大規模なACL
- 拡張されたトンネルスケール
- アプリケーションテレメトリー(Inbound)
- フレキシブルルーティング

## Arista EOSアーキテクチャ

- Linuxカーネル(Fedoraで作っているので、bashでいける)
- Agent 各プロセスはそれぞれユーザアドレス空間で動作
- モデルはPub/Subで疎結合になっている。Sysdbがすべての状態を管理

## デモ

barefootのagentを入れる感じになる。
profileを切り替えるやりかたもできるし、rpmパッケージでインストールすることもできる。

最新版のEOSでは下記のプロファイルがある。

- baremetal
- mpls_baremetal
- nat
- default
- l2subintf

要望があったのでLBはEFTで作り始めている。
また、お客さんカスタムプロファイルを動作させるようなこともできるようになってくる。

## Summary

- 7170はBarefoot TOfinoを搭載したプログラマブルプラットフォーム
- EOSはbarefootも含む、全てのシリコンをシングルバイナリーイメージでサポートする
- Aristaエンジニアにて提供するプロファイルもあり（すでに5つ）、既存の機能が使用可能（４つほど追加される予定)
- ユーザー定義もしくは追加プロファイルは、プラットフォームのバージョンアップやリブートをせずに追加可能

# Cloud-Grade Routing Stack for P4/Stratum

Juniper 有村さん（笑）

## Juniperのラインナップ
まだP4対応のスイッチは持ち合わせてはいませんが、
JP4 Agentというものがある。githubにある。
https://github.com/Juniper/JP4Agent

使いたければ連絡すれば動かせる

## JUNOSの進化について
featureの追加とか、Agentごとの開発なのでメンテナンス性が高いとか。

## CRPD Container Routing Protocol Daemon

最近の流れとしてはプロセスをコンテナにしてしまおうという話に乗っ取って、2019夏にリリースしました

Container上にDeployしてもらってろぐいんすればJunosも動いていて、OSPFとか入れるとそのまま動くはず。
その他のコンテナがユニークなアドレスを持つのであれば、OSPFからその他コンテナのアドレスをOSPFから広報したりすることができる。

>[name=Togasaki]同一装置内で複数のコンテナを立ち上げて使用するということですか？
>[name=Tomoya Watanabe]うん。そうです。
>[name=Togasaki]別の装置としてそれぞれP4/Netconf/CLIなどを使用して使いたいNW設定を入れるということですか？
>[name=Tomoya Watanabe]これは全くP4関係ない。とあるIAサーバの中に、192.168.1.1 Web 192.168.1.2 DBとかいうコンテナを動かした時に、このアドレスをOSPFが動いているContainer上のJunosから広報できるといっている。ただ、それって192.168.1.0/24を広報するのと何が違うの？っていう疑問はあり。ありえるとしたら、/32で個別のIPアドレスをコンテナに割り当てた時にそれをNWに広報できるなら柔軟（？？？）なNWになるかもしれないけど、あんまりユースケースがよくわからない。ただ、Container基盤になるとどのIAサーバにどのContainerが動くかわからないから、柔軟な設計になるっていうのはありなのかもしれない。気持ち悪いけど。
>

# 進化するデータプレーンプログラマビリティ
Apresia 桑田さん

## Apresiaについて
ホワイトボックスSW：P4 BarefootのTofinoチップを搭載
P4 ver14/ver16が存在どちらもサポート
SELAを結びBarefootとは協業してる
BarefootにはTofino2も存在

Barefootのハードウェアを動かすために必要なSDE

## P4動作デモ
1. エミュレータ起動
2. ドライバ起動
3. テスト実行（P4記載した条件を実行）
　　- SDEから所定のコードで条件を書くとテーブルが作成される

>[name=Tomoya Watanabe]P4はテーブルを生成するプログラムっていうのはNETCOPEのときもいってたから、基本的にはテーブルを定義した後にレコードを入れていくっていうのがアプリの設計になるんだろうと思う。実際触ってみないとちょっとわからないけど。
>で、そのテーブルの中に直接エントリを入れるのを普通のP4 APIでできると思うんだけど、実際に流れてきたパケットからエントリを入れていくのがDigestという機能なんだという理解をしてる。P4-SDKからも書き込み可能
>[name=Togasaki]いまだにbarefootとsonicのイメージがよくついてないです。
>[name=Tomoya Watanabe]　barefootはTofino(P4 Programable ASIC)というチップを作っているメーカー。SONICはMSが作っているOSSSのNetwork OS(NOS)
>[name=Tomoya Watanabe]大体並列だけど、stratumはP4に特化しているNOSで、Sonicは特にそういうわけではないという印象。
>[name=Togasaki]そうなんですね。。
>

実行時の参考画面

P4内処理

# In-band Network Telemetryとその可能性
NOS 新林さん

## P4に期待していること
5G時代に求められている高信頼性と低遅延をどうやって両立していくか？
そんなところでP4が使えるのではないかと考えている。

>[name=Togasaki]srv6とかがユースケース多いんですね

## INTについて
パケットをSWの上を通る時にINTのメタデータを付与してコレクターに集める
ドロップなどの情報も集める

パケット情報の可視化ツール：barefoot deep insight
https://www.barefootnetworks.com/products/brief-deep-insight/

Push型監視
　- Telemetry　flowの情報まで紐づけられる
　- xFlow NW全体の情報がわかる
　- INT　パケットが通った形跡がわかる、処理時間がわかる
　- etc..

INTはメモリの負荷が増えてしまう。。。

>[name=Togasaki]デモ動画でUIが揺れてて面白い。。。