作者简介：一名虚拟网搬砖的码农
前言
写这篇文章的根因呢，是差不多一年前看到了这篇文章：《SR IS SDN DONE RIGHT! OPENFLOW VS SEGMENT ROUTING》
文章地址：https://abuhayat.me/sr/
为什么拖了这么久才写呢，文笔拙劣，容易烂尾，也没抽出时间理理。导火索是刷到了一个量子延时擦除实验的视频，好像有点 get 到量子力学那味儿了，随即感觉到了以前所谓的一些科普文章对我的智商侮辱，凭着爱好了解了解物理，本来就没什么途径，一些人还要误导圈外人。我既然从事着虚拟网这行，空了也写写文章，主要帮助自己整理思路，若是锦上添花能给到看到博文的人一点点有用的帮助，那是再好不过了，当然，还有稿费。
回到开篇提到的文章，其主旨就是 —— Don’t program the flow (in the network), program the packets。简单说就是 SR Clarence 教徒怼 OpenFlow Nick 教徒，其实作为传统网络出身的我，之前一直站队 SR，也写文章喷过 OpenFlow，这篇文章写得比我好的不是一点点。但是，从事虚拟网以后，想为 OpenFlow 说上几句，这不是 SDN 思想之争，诚然，物理网中如文章作者所述，SR 才是正确的路（有意者可以翻看下这篇文章），我也一直坚信如此，不过我估计那位作者应该没有什么从事虚拟网的经历，我觉得他并不了解虚拟网需要的是什么，我不去争论什么，就谈谈我在虚拟网的打怪升级之路吧，阶段就类比我写这篇文章的导火索——对量子力学肤浅至极的认知阶段吧，对于主观看法，笔者也在不断地学习和接受新知识，保留自省的权利，我特别喜欢别人说我是错的，但又讨厌其坚定自己是对的，多多交流喽。
悖论——邂逅OpenStack
也许你听过著名的薛定谔的猫思想实验，但未必清楚薛定谔提出它的初衷并不是帮助大家理解量子力学，而恰恰是由于他无法接受量子理论里面诡异的世界观，提出这个思想实验的目的是告诉大家量子力学有多荒谬，所以他决定放弃。这里我不得不愤青一下，那些以科普的名义，让别人为其无知买单的行为真是有够讨厌的了。
传统网络出身的我迫于生计跑到网络安全界溜达了一圈，看着 OpenStack 举着开源云计算的大旗一路攻城略地，它携着 SDN 的风潮使我水到渠成的加入了进去。刚开始，总会听到一句“做云的人不懂网络”，其实俗人一个的我难免有点小窃喜的，毕竟这就侧面说明从网络过来做云的我在行业竞争中还是有点优势的。随着对 OpenStack 的深入了解，我只能感叹做 OpenStack 网络的这些人哪是不懂网络，炉火纯青的学以致用说的莫过于此了，其总能以最优雅的方式兼容乱七八糟的网络情况实现目标需求，至此，我不再从那些只会 cli 大法的 CCIE 们那里感受“小窃喜”了。不过，我还是想把这个头衔给到某些人，有次面试某大厂的 OpenStack 系云网络岗位，当时面对规模压力和 K8S 的借鉴，正在赶去 MQ 的大潮，控制面聊了这些还蛮合得来，数据面赶鸭子上架扯了扯各种优化手段，但当我诚恳地跟他探讨网络这一路的演变和思想时，他却以上位者角度全盘否定，真是对牛弹琴，索然无味。
接着，我去了另一家 OpenStack 系魔改版云计算大厂，也是在这里，我结束掉了与 OpenStack 的缘分。因为我觉得这样的网络简直是一塌糊涂，如果说云计算是解放生产力，那么这里就是在圈地赚租金。至于为什么会这样，也许是摸石头过河的历史原因，也许是未知的利益因素，亦或是这些太懂网络的人同样也没好好想过虚拟网的真实诉求。
原谅我文笔不好，不能准确的描述出来现象和表达感受，技术细节也不太好透露，我就拿开源的两个方案举个例子吧——L2Population 和 DVR。
这俩显然不能归类于我前文所述的优雅，而是 OpenStack 宣称的 SDN 网络的最后尊严，但我对这两者的看法却完全不同。
虚拟网在同一层面上构建模拟路由交换，大二层规模性能就是个严重问题，L2population 是一个巧妙地 SDN 倾向型妥协吧，利用控制面的信息辅助收敛，抑制大二层报文泛洪和长尾隧道的链接压力，很好的解绝了问题且与原先的网络架构相辅相成。
DVR 就另当别论了，它虽然能解决掉网络节点的压力，但既然选择了 gateway 这种模型，这种背离路由交换的思想真的是难以让人苟同，直接来看看我N年前画的一个流量路径吧，也许现在有出入。
顺便再提一下传统网络厂商为了吃到云计算这块肉，硬凹的分布式路由，这里就给出了跨子网对称路由的报文封装，路由通告和非对称路由我就不贴了。
啧啧，前者一套懵逼组合拳，后者任尔东西南北风。
这里又不得不提一下 OVN，算是能稍微整顿下 OpensStack 网络的控制面了，但其 multiple L3 gateway 的支持也要基于源 IP 地址在 gateway 之间分发流量，这里就不好说什么了，只是转发模型定义之争，但其采用的是 SDN Pre Programmed 模式，网络复杂度是网络规模的 O(n2)，转发模型暂且不论了，既然放弃了网络的分散协作，全面拥抱 SDN 的暴力美学，这种 full-mesh 除了在一致性和性能可预测性上稍微占点优势，我不明白既然已经放弃了在网络方面一直坚持的所谓优雅，何不再走出去看看，于是我来到了一家主打 On Demand 模型的云计算公司，正式步入下一阶段。PS：其实由于时间和精力有限，目前为止我仍是依据包装就判断放弃了 OVN 的品尝，但其实蛮想看看 flow 的细节设计的，欢迎有吃过的人能告诉我它是什么味道。
不同于薛定谔的猫，诸如车轮悖论、罗素悖论此类，尽管其本身也是假的悖论，但却是推动进步的强大动力。说谎者这种真悖论却是辩证法看待事物下的必然产物，其自我否定的不可证伪，更加体现了矛盾律的正确。OpenStack 亦如是。
二律背反——Hello World
双缝干涉、量子延迟擦除这些实验都是很经典的量子力学实验，有兴趣的小伙伴可以了解下，反正我是简单了解后，脑中已经补完了几部什么平行世界、时光穿梭的科幻大片了。
正如刚知道这些实验一样，刚正式踏入 OpenFlow 主流玩家圈子的我，也满是好奇，天天都有新想法，也天天被事实打脸，就这样在不断地头脑风暴和思想碰撞中重塑认知。
其实，回过头看，这里其实和 OpenStack 的目标一致，但由于切入角度不同造成了完全不同的思考方式。OpenStack 就像在由已知求解答案，堆砌网络技术，广而兼之，而这里就像在用一门新的语言去表达，切合原始需求精耕细作，但实在可惜的是，由于网络协议这些老大哥的存在，稚嫩的 OpenFlow 只能表音，无力表意。厚着脸皮说声，我貌似在这里才 get 了虚拟网本身的诉求。
不过，家家有本难念的经，Packet-In 模式的首包延迟、脏 flow 、DDoS、异构网络等问题也是个烦心事，还好能看清前进的道路，Google 的 Hoverboard 模型就给出了不错的答案（为什么不@云计算头部玩家 AWS 呢，因为其把所有网络功能下沉到专门硬件的方式不是 SDN 的菜吧，得叫它兄弟 NFV 唠唠），集百家之长，这些在这里就不多说了，我想谈谈一些我自己的想法。
二律背反不是上帝的戏弄，其应该是我们用实践不断去求解真理的原动力。
不管上帝会不会笑，思考总不会是坏事
这个阶段便意指看了实验视频恍然大悟吧，笔者个人觉得没有那么玄学了，如 Zurek 所说：“干涉仍在，只不过它不在任何地方了”，“未来决定现在”的真相也就是 Greene 所说的“未来只是在帮助我们讲过去的故事”。言归正传，我主观大胆地谈谈我所认为的虚拟网应该是什么样的。
首先，听人说过，“VPC的终极愿景就是提供如真实的物理网络一般”，我却不这么认为，我觉得应该是更好的为应用抽象提供底层的网络资源。简单点说，就是什么 network、subnet、switch、router 等等，这些由于物理、系统设计等原因一个个搞出来的概念不是非要搬到虚拟网上，因为虚拟网面对的是截然不同的底层问题。回归网络本质需求，无非是连通性 True or False 的问题，再基于此添加高级功能。有个不成熟的想法，抽象给客户的网络资源就是一个地址空间，干嘛要客户理解传统网络那一套，不仅增加客户的学习成本，也增加我方的难度，地址空间内默认连通，不同地址空间打通在以地址不重叠的前提下打通 VNI，还能附加 metric 之类的控制连通的传递性。
下一个问题，在完成东西向流量点到点传输后，我们还要以控制面和数据面割裂的代价去模拟传统网络的路由交换么？仔细想想，switch 面对的问题与虚拟网 Local 转发的问题一致，Route 面临的问题在虚拟网里其实应该是只有一跳的 Location 查询。接着，提一个初学网络基本都会产生的疑问——为什么有了 Mac，还要 IP ？也许你会直接涌上来一堆答案，但我在这里想强调的一点是，Mac 的本质作用是标记，而 IP 的作用才是网络收敛和寻址。
当几台主机在一个冲突域内通信时，Mac 是作为判断来源和与己相关性的，这是一种标识，因为信号是在传输介质中扩散的，后面有了交换机作为缓存转发优化，隔绝了冲突域，但想想广播域的通信过程，并没有什么收敛和寻址，全靠吼，如果非要把交换机的 Mac 地址学习和单播转发算作收敛和寻址的话，我无话可说。
那么理想状态的虚拟网应该是什么样呢？首先是一个依靠 IP 寻址的全三层网络（诶，对于二层的硬需求像帧中继和 ATM 一样扔掉吧；至于所谓的大二层在自行收敛时还是有必要提的，可回头看看从云计算网络诞生到现在我们有多少依赖 vxlan 收敛 FIB ，gre 也照用不误不是？），与原先协议冲突的地方，比如 ARP 广播直接随意代答就好，目的只是要控制面不保留 IP、Mac 以及 VNI 之间的关联信息，只保留 IP VNI2Location 的信息，关键 flow 是依靠 VNI IP 得到 Location，这就是类比于传统网络的一跳 Route，而没有Mac 信息如何送到 VM 上呢？其实这就是前文提到的 Mac 只是一种标记，这跟得到 output 端口并无什么本质上的区别，那么最后在目标 OVS 上如何改写正确 Mac 信息并从正确的 output 口扔出去呢，这不就是传统 switch 面临的问题么，Local 本地设法维护一份 IP VNI2Mac Port 的数据就好，不涉及控制面，数据面自治。
至此，还有一个比较关键的问题，就是 VNI 信息的来源，暴力简单点依然是依靠控制面维护映射关系并推送，但 VNI 同 Mac、Port 本质一样属于标记信息，建议还是数据面直接处理最好，这里给两个解决方案：使用 802.1q 或 802.1ad 直接转 VNI；规划 Mac 前缀用于标识 VNI。
接下来呢？没有了，什么流量调度、拥塞控制的一堆不正是 underlay 的 SR 该做的事情么，他们是不具有排中律前提的两个命题。
愿 SR 和 OpenFlow各自占山为王，庐山的美也是这种相得益彰吧。
