#L2overL3 参加メモ

2014/07/17らへんのもの。
※他ページからQiitaに移動

現在は、VXLANはRFC7348になっている。

[@motonori_shindo](https://twitter.com/motonori_shindo "@motonori_shindo")さんによる、「L2 over L3トンネル方式について考える」のメモ。
資料は[こちら。](http://www.slideshare.net/motonorishindo/l2-over-l3-ecnaspsulations "資料")とてもありがたい。

目次
------

* VXLAN、NVGRE、STT、Geneveについて
* 疑問点など
* Geneve反対派の意見
* 質疑応答

VXLAN
-----

* 正式名称は Virtual eXtensible Local Area Network。
* 他のもそうだけど、まだRFCになってない。draft。
* VXLANのモチベーションは？
    * 現在、VLANに問題をかかえてる。4096問題とか。
    * どうにかしたい。VLAN IDを拡張したい。VLANを置き換えたい。
* VNIは仮想ネットワークを識別するためのID。
* UDPを利用。UDPな理由はマルチパスを利用できるようにするため、が主軸。
* VXLANはHWで処理がしやすいように考えられたフレームフォーマットを持つ。
    * シンプル。ヘッダにはほぼVNIしかない。あとはRESERVEDが多い。VNIがあるかどうかのフラグ(常に1)くらいしかない。
* いろんなベンダ、とその機器がサポートしてて、エコシステムになってる。
* 従って相互接続性が高い。
* マルチパスのため、元パケットのヘッダをなんかしらハッシュして、カプセルのsource portに設定する。
* destination portは4789。

NVGRE
-----

* 正式名称は Network Virtualization using Generic Routing Encapsulation。
* これもまだdraft。でてきたのはほとんどVXLANとおなじ。
* やっぱり有名企業がおおい。Microsoft社が中心だったりする。
* これもシンプル。やっぱり仮想ネットワークでの利用が前提で、VirtualSubnetIDとFlowIDをもってる。
* FlowIDはマルチパスのために用意されたもの。GREは位置的にL4であり、そのヘッダにはポートが無いから。
* NVGREは新たカプセルではなく、GREそのもの。
    * GREは柔軟なフレーム構造になってて、こういうフィールドがある、ないをフラグで示せる形をしてる。
    * GREは可変長のカプセルで、いらないフィールドはつけなかったりする。
    * NVGREはGREの１個のフィールド（Key）だけをつかう、っていう規定をしてるので、NVGRE自体は固定長。
* マルチパスは理論上できるらしいが･･･
* 重要な差別化ポイントは、Windowsと親和性が高いこと。
    * 逆にWindows以外ではあんま使われてない？
* ヘッダにはProtocolTypeがあるが、NVGREはペイロードにEthernetフレームを置くことを前提にしているため、0x6558固定。
* NVGREというかGREはポートがないのでVXLANみたいにsource portとかでマルチパス実現ができない。
    * そこでFlowID使うが、GREの中身覗いてFlowID見る機器は少なくて、やはりマルチパスの力を発揮できないことが多い。
    * サポートしてるルータはHuawai社のもの。
    * レイヤ上のだとF5 Network社もサポートしてる。
    * NICだとEmulex、Mellanoxがサポートしてて、NVGREオフロードに対応してるらしい。
        * Keyまで見てハッシュする機能があるかは不明
* VXLANほどサポートされてないのが実情。

STT
---

* 正式名称はStateless Transport Tunneling。
* VMWare社（というかNicira社）の提唱してるL2 over L3カプセリング方式。
* これもドラフト。RFCはInformationalを目指している？
* VXLANとNVGREあるのに、なぜSTTつくったのか？
    * 性能。他のに比べるととパフォーマンスをだせる。
        * TSOをフル活用する。コンテキストスイッチングを減らましょう。
            * カプセリングを**TCPのようなもの(見た目はTCP)**で行い、NICにオフロードさせる。
            * 実際はTCPではないので、そこはStateless。
            * STTヘッダは分割された最初のセグメントにしか付かない。
    * 拡張性。もっと多くのContextを運ばないといけないと思ったから。
        * VXLANとかで運んでた情報って、ほとんどVNIとかVSID。仮想ネット識別するだけのもの。
        * 仮想ネットワーク作るには、ネットワークの識別だけすればいいわけじゃないと考えた。
        * もっと複雑なものいるはず。ServiceChainingとか。
        * ContextIDという用途自由な64Bitフィールドをもっていて、ここをどう使うかがコントロールプレーン実装ベンダの腕の見せ所。
* ソフトウェア寄りの仕様になっている。
    * どういうことかというと、endがHypervisorになることを考えている。
    * NICさえTSOをサポートしていて、endがソフトウェアであればよく、同時にSTTを使える条件でもある。TSOのないNICは殆どない。
    * 逆に、STTをサポートするようなハードウェアは今後も恐らくでてこない。
* DC内での利用がメイン。
* マルチパスをうまく効かせるために、TCPのようなもののsource portにペイロードのヘッダのハッシュを入れている。
* destination portは7471を申請中。

Geneve
------

* 正式名称はGeneric Network Virtualization Encapsulation。
* 読み方はジュニーヴ、らしい？ジュネイヴっていう人もいる。
* 最近できたばっかり。draft。

* Geneveのモチベーション
    * 今までのでは満たせないのを満たそうと。
        * 拡張性。固定長のフレームだと拡張の余地はない。STTは64Bitなんで今は十分かもしれないけど、将来たりないかもしれない。
        * Service Chainingとかをできるようにしたい。これやろうとするとき固定長カプセルだと厳しいかもしれない。
        * TSOも活用したい。
        * ※可変長かつTSOはどこからTCPセグメントかわからないので難しい。
    * 拡張したもの
        * TVL。OAMとかも入った。あと、TSOすべきかどうかをNICが判断できるように。
        * ProtocolTypeも持ってる。Service Chainingが目的らしい。
        * VNIも持ってる。
        * 要するにVXLANにProtocolTypeとオプションが付いたようなデータ構造。

* 実装は？
    * OVSにマージされた。master branchに入ってるから、自分でbuildしましょう。
    * 肝心のoptionがまだ使えない。というか、どういうoptionがあるのか決まってない。
        * 別のdraftがでてくる予定。
* Geneveの解析は？
    * WiresharkにもGeneveのdissectorがはいったから解析できる。これもmaster branchに入ってるから、自分でbuildしましょう。
* 使えそうなの？
    * 真価を発揮するのはGeneveを認識できる、Geneve-AwareなNICができて、オプションつけられてTSOもできるようになったとき。
    * まだそういうNICは世の中にない。これから。

疑問点など
---------

- Geneveはほかのトンネルを置き換える形になっていくのか？
    * VXLANを置き換えることになるの？
        * NO。VXLANのエコシステムは非常に大きいので、Geneveで同じことができるようになってもたぶんVXLANはなくならないし、これからも成長するはず。

    * STTの置き換えは？
        * 短期的にはNo、長期だとあるかも？GeneveはOVSに実装されたけど、すぐ置き換えられることはない。まだサポートしてるNICがないし。
        * そういうNICの普及に伴って、もしかすると徐々にSTTはなくなっていくかも。

    * NVGREは？
        * これも短期的にはNo、長期だとあるかも･･･
        * NVGREの運命はほぼMicrosoft社が握っているので、もしWindowsでGeneveがサポートされて、Azureでも利用可能になって、とかいう事になると、なくなっていくかも。

- トンネルの方式って、結局どれが主流なの？
    * どれかが主流ってこともない。適材適所。
    * Hypervisor - Hypervisor はいまのとこSTTでやるのは理に適っているし、ハードウェアをendにするならVXLANとか。
    * 混在しててもいいし、使い分けが重要。

Geneve反対派の意見
-----------------

Geneve反対派の方々も当然いる。

* 新しいの作るんじゃなくて既存のVXLANとかの拡張でやってよ。
* ServiceChainingとかMedatadaを運びたいニーズがあるし、そういう団体あるのもわかるけど、そのへんとカプセリング方式ををBindすべきじゃないでしょ。
    * カプセリング自体の拡張性にしなくていいでしょ、という事。
    * 別の団体で別のヘッダを定義しようとしてるんだし、混ぜなくてもいいんじゃないの。
    * ※ ⇒でも、Geneveの拡張性はServiceChainingとかMetadataのためとは限らない。
* VNIは24Bitじゃ足りないだろう。


回答？
-----

* 既存拡張でできないか？の主張
    * L2TPv3　Static Tunnelingでどう？
    * Signalingつかわずに両端に静的に設定をして、カプセルとしてだけ使うこともできる（L2TP StaticTunnel）。PseudoWireとか。
    * L2TP自体はTransportFreeだし、マルチパスも満たせる。
    * L2TPには昔、オフセットがあったから、それを使ってどこからTCPが始まるかもわかってTSOいけるんじゃないか？

* VXLAN拡張は？の主張
    * VXLAN GenericProtocolExtention （eVXLAN、VXLAN-gpe）
        * 元々RESERVEDだったエリアにNextProtocolいれたくらい。あとバージョンとかOAM。
        * NextProtocolはNSHをうまくカプセリングする為にいれてみたやつ。8ビットしかないので、本来のプロトコルタイプとは違うマップ値が入る。
        * 実装はCisco ACIですでに存在。
        * 拡張性はないけどNSHに対応してService Chainingすることはできるかもね。

質疑応答コーナー　(拾い切れなかった)
---------------------------------

* アンダーレイで考慮することはありますか？
    * あんまりない。けど素性のいいネットワークのほうがいい。
    * あんまり縛りはないし、既存を置き換えるものではない。オーバーレイだからなんでもうごく。

* DCを跨いだ通信をやろうとしたときにマッチするのはどれ？
    * WANに向いてるかどうかって意味ではどれも大差ない。本質的には。
    * 実装に縛られるところはある。MTUのサイズとか。
    * どのカプセリングで、というのはどのトンネルでも大差ない。