网络服务化与供给侧改革：退一步海阔天空

题记

昨天跟某司几位领导聊了一下，然后晚上又读完一篇文章《Gartner报告：SD-WAN和NFV的企业网络服务市场趋势》，有一些感受，写点东西。

过去十多年的经历深刻的感受到了应用和网络的割裂，应用的开放融合快速发展对应着网络的寡头封闭，特别是在应用完成虚拟化然后容器化云化后，而网络还在NFV上停滞不前。终于有一天，应用开始自己搭网络了，虽然初期很笨重，大量使用Tun/Tap和Iptables，但是各个寡头在被应用侵占的时候，终于意识到这个问题，开始大谈Network as a Service（NaaS)了,也就是国内常说的网络服务化。但在这个过程中还是免不了塞自己的盒子和夹带私货的思想，还同时想继续争夺控制权。现实就是你不得不妥协，在这一场网络供给侧改革中，不是简单的给几个控制器API给应用，而是通盘的考虑如何最大化的给应用服务。

既然是网络供给侧改革，咱们先耐心的看看存在的问题，再来谈怎么改。有些话很难听，良药苦口利于病，请您别急着摔手机，耐心看完。

1.兵败SDWAN

说实话现在的SDWAN没有一个让我自己觉得满意的，而世界上除了几个大的收购整个产业也没几个人赚到钱的，即便是高价格收购的那些企业也没见几个能完全变现的，反而是更加激进的投入进去完全没有产出。过去几年亲历了某厂自己做烂了一个SDWAN然后又买了一家，然后市场上虽然有很大的呼声，落地部署却又是另一回事，静下心来好好的梳理了一通，才发现原来是SDWAN这种惯性的思维本来就是错误的。

1.1 不思进取的产业链

现在的互联网应用基本上一个月两三个版本都是常态，而通信行业通常一年就三到四个小版本升级。更有趣的是通信人还以那种很老的思路在说：应用很难改的，代码要利旧的，于是就这样僵化的前行着。而通信行业的保守还来自另一个方面，多厂商设备的协同导致标准制定的时候相互的妥协，协议发展长期停滞不前。

每当谈到安全加密的时候，几乎所有的厂商都在用IPSec，而谈到路由协议的时候都是用BGP。某司当年做IWAN废掉了就是这个原因，IPSec在震荡的时候由于密钥交互阶段大量的RSA运算和复杂的交互消息和加密算法协商使得局端收敛特别慢，例如某拱门或者某住酒店很多年前就有几千个门店通过IPsec连接到局端，通常一个Hub能够稳定运行服务的分支数量大概也就在1500个左右。

另一方面是BGP，路由协议本质就是一个分布式一致性问题，陈旧的算法使得收敛特别满。最近一些年应用侧随着Paxos或者Raft协议实现的分布式一致性协同系统已经有很多了，但是大多数做通信的人还是没想清楚问题，继续做着BGP的扩展。MP-BGP(VPNV4/V6)或者EVPN有着它独特的发展史，因为有些MPLS随路Send-Label的需求，但业务模型在BGPEVPN+VXLAN的数据中心SDN或者BGP+IPSec的SDWAN已经发生了变化，本质上只是通告一下Overlay和Underlay的Mapping，根本不需要防环机制，却被BGP自身的一些特性折磨着，例如RR的部署，IBGP的限制，其实根本就不需要AS-PATH的属性。BGP收敛慢也是出了名的，但不知道某个云为啥会想到一个“集中式BGP”的处理方式，真是莫名其妙。所以思科的ACI在设计的时候压根就没有考虑过在Fabric内部使用BGP，直接简单的一个COOP协议做KV Mapping就好，在边界和传统设备互通时才使用BGP-EVPN

在数据中心和园区内实施SDN有它特定的场景，有足够大的带宽，足够低的延迟和足够的链路可靠性做保证，而且园区中通常也有足够多的计算资源用于控制器扩容。

但是整个行业莫名其妙的就把这些东西嫁接到SDWAN上来，简单的按照SDN的思维去抽像，Yang Model继续用，BGP继续上，IPsec继续玩，然后搞了那么一套东西出来。所以某司很容易的选择了DMVPN+BGP/EIGRP的方案，而另一个也自然而然的选择了DSVPN+BGP的方案。同时为了差异化竞争，某司还在上面搞了一套PfR动态选路，最后发现分支和核心经常有一系列不一致异步路由的事情，于是又在上面做加法。最后形成了BGP/EIGRP+NHRP+PfR，一个广域网三套路由协议的荒唐事。

1.2 丧失分布式系统设计能力

通信业另一个问题便是对分布式系统设计没有太多的认知能力，在分布式不一致的情况下，几乎所有的人都认为把这些东西弄到控制器上不就行了？于是又是一场轰轰烈烈的改革，把路径计算引擎上移，虽然全局的SPF计算可以使用Floyd这样的算法，但是SDWAN更多的是为了在满足SLA的情况下尽量多的使用链路带宽，因此约束算法可能会是基于不同Metric的Dijkstra，然后实现Dijkstra的时候，很多人随手一个O(N^2)复杂度的标准算法，这样在控制器上的复杂度变成了为N个节点，M个应用计算O(N^2)次，基本上时间复杂度就是O(N^3)了。控制器处理不过来了自然就开始堆集群。

然而很多通信人并不是学CS的，参加过算法竞赛的人也非常少。通信网络中的边权重不会为负值，因此通常在做Dijkstra的时候，我会实现一个带堆优化的Dijkstra，这样时间复杂度为O(N*LogN).

另一个方面就是Netconf/Yang Model，大量的XML的封装传输开销非常大，而协议解析也非常缓慢。在数据中心和园区相对来说并没有太大的震荡需要处理，因此看上去这样的东西工作的还算不错，而在SDWAN它又带来了一系列灾难了，单次变更伴随着广域网络延迟通常需要大量的错误处理和长时间的等待，设备一致性和故障回退也成了一个麻烦事，传统的基于命令式的API结构和编程思维使得故障回退几乎不可能，因为变量赋值本身就有副作用。因此大量的企业又把一些业务逻辑继续上提到控制器，还美其名曰数字孪生。

所以几年前我在某司拿某个创新大奖的时候的做法就是尽量的简化控制器和设备的业务逻辑，并将其抽像为简单的KV结构使用Raft一类的协议完成一致性，由设备自主完成同步。另一方面把网络协同信息和路径信息下放到设备，由设备自主选择。继而把遥测数据在网元上自主协同处理，并进行AI赋能，使用AI模型来进行最优化决策并利用异构芯片加速运算，也就是最终完成设计的Ruta架构。

注:Ruta架构可以参考： 

很高兴的看到华为昨天发布的ADN也有了AI+网元的赋能，行业就应该在这种激烈的竞争中互相进步，而不是受其它各种因素的影响。

2.搞不懂编程的P4

这几年通信人最喜欢说的数据面可编程一个就是P4，另一个SRv6，再加上Yang Model就逼着一堆网工开始写代码了...网络的可编程能力在哪？本质上你需要明白它只是一个针对I/O密集型业务的并行程序设计模式。

实际上I/O密集型应用的处理方式，一种是Pipeline模式，另一种是Run-to-complete。时至今日你也会看到Pensando vs Fungible便是pipeline vs RTC，Barefoot vs Cisco Silicon One也是同样的Pipeline vs RTC。业界一直对于两种处理模式争论不休，但你同时也需要注意到Intel在偷偷的增加ALU的复杂度。

所以几个月以前也发了一文：《“网络编程” 还是 “可编程网络”？》

最终的妥协就是部分操作可以并行化完成的，可以在SIMD指令中处理完，例如VPP这样的处理方式，所以在网络业务编码的过程中你一定要考虑这一点，如何能够让硬件实现快速的批量更新，SRv6的SRH设计便是一个极佳的工程案例。

但是我们还是需要妥协其它一些业务，带有可约束执行时间的RTC或者便是这两者的最佳妥协，对的我说的就是BPF。所以你看到Cilium这样的项目出来以及基于BPF指令集设计的众核智能网卡，以及有一些从P4编译到BPF的开源项目都有它存在的价值。

3.退一步海阔天空：供给侧改革在传输层（L4）

说到SRv6的问题，主要是在产业结构上，应用侧对SRv6几乎不感冒，一方面它强制约束了Underlay协议必须是IPv6，这种强假设在国内很好办，国际上却可能有些困难，涉及到基础设施建设的问题，当然很多人假设运营商网络都已经双栈了，问题在哪？那些终端的小盒子。升级SRv6的改造通常需要Kernel的更新，这些小盒子。而应用要使用IPv6的Option Header通常又需要特权。

网络的人总喜欢在3层一下搞事情，因为无法控制应用在传输层用什么协议，这是SRv6设计时导致的问题，当然类似于康威定律那样，很长一个年代网络和应用都是分开两个部门的，自然体系结构也就在L4上断层了。

供给侧改革的重点自然就该在传输层了，网络做上去一点，应用做下来一点。

3.1 网络的准入控制

昨天跟一位领导聊到这事，这其实是网络里面最困难的一件事，做到了终端和应用可识别，可管，可控就完全的实现了智能网络，但是很遗憾的是网络自身做不了一定需要和应用妥协以及和应用的协同。过去几年我也很烦一件事，打开电脑要输一次密码，登录公司VPN要输入一次密码，登录公司应用系统还要输入一次，然后双因子认证还把原本三次搞定的变成六次，痛苦不堪。应用侧通常使用基于Token的机制实现了SSO，并通过它完成了全业务链条的监测。而网络呢？是否能够各自退让一步？让应用把Token放到L4Header以后的固定位置，而网络也同步读取这个头进行验证和策略处理？身份验证应用识别及后续的流量调度和随路监测都可以实施了。

当然这么做还有另一个原因，我们来看传统的网络，通常为了安全策略需要配置大量的ACL，如果看成是一个基于源目的地址和端口构建的三维空间来看，ACL是在进行一个超平面切割空间，这是一个线性切割的过程。

所以有些时候我们在做出的取舍是根据业务和身份编址，这样可以降低ACL的使用率，但地址更加零碎了，路由表的条目就多起来了。所以通过编址的方式无法在SDWAN环境中解决这个问题。那么接下来就是映射咯？但是映射本身我们又犯了一个错误，当年思科做TrustSec或者ACI是因为仅有几个字段可用的情况下，只用了源Group-ID作为SGT/EPG，然后在ACL容量上和IP路由表上做了一个取舍，但是这种非满秩的映射带来一个问题就是目的IP地址对应的SGT/EPG需要整网同步，在园区和数据中心很完美，到了SDWAN那里又出事了。

这样的做法在数据面上通盘考虑也不高效率，每一跳都要查路由表的同时，还要查询目的的GroupID，所以未来是什么？更多的是让中间设备尽量傻一点快一点，业务映射在两端完成，在流量建立初期携带，中继设备快速构建流表。所以这也是我在设计Ruta是需要考虑的一个问题，最终的数据包标签应该如下，Policy Label也就是那个应用层和网络层结合的Token。

这个Token直接也可以做为施加流量工程的Binding-SID存在，同时由于它的存在，把IP地址五元组解耦了，也就是说当你在WiFi或者5G漫游的场景中，无论你用哪个链路连接，服务器都能做同样的处理，所以你会看到QUIC协议中的CONNECTION-ID也有异曲同工之妙，而移动网中的GTP-TEID也是类似的做法，通过这样的Token完全将云端应用和固网以及移动网打通了。具体可以参考这文：Ruta架构：5G/MEC环境下的移动性和可追踪性

3.2 端到端的网络赋能: 给应用选路的能力

讲到这里，就涉及到一个通盘的架构考虑了，很多大的企业的架构师只做过一小块内容，按领域分通常为数据中心/园区网/移动网络，按行业分运营商和企业网也有不同，产业链里只有极少数的人全盘做过，那就是被夹在数据中心和园区网中间的做多业务路由器的人，数据中心会谈Application Centric，园区网会谈User Centric，在中间被他们扯得蛋疼了好多年的我还要不停的妥协去符合他们的要求，最终SDWAN的产品做的越来越重，安全的厂商也混进来了，应用加速的厂商也混进来了，各自夹带着私货。

端到端的协同能力出现转机在应用侧，应用终于看不下去了，开始搞ServiceMesh了，然后一个Sidecar上来再加上HostOverlay，基本上宣告ToR上Overlay凉了，流量模型也发生了极大的变化，但是另一个问题被提出来了，如何解决数据中心或者园区网的东西向流量的拥塞？

数据中心0.1%的丢包会导致AI训练性能下降50%，但是即便做到零丢包性能还能继续提升么？延迟也是一个大问题，分布式协同才是关键。

所以Ruta设计的一个场景就是通过应用自己选路中继的方式实现和网络设备的协同，SR源路由的思想也就用上了，所以你会看到基于3D-Torus拓扑构建的分布式机器学习通信框架，因为我自己也做大量的AI相关的研究经历产生的，通常做网络的人并不会想到，Ruta for AI：分布式机器学习的网络优化

另一个问题来自于视频会议系统的优化，因为我做过SBC，对于这种应用侧可编程的边缘Relay技术非常熟悉，也就是利用SIP消息中SDP携带SBC Media Address的方式使得语音视频流经过特殊的设备构建UDP Pinhole完成确定性的转发路径，Ruta只是把这种随路SIP信令构建的有状态转发流表变成了使用SR的无状态源路由，所以你会看到Ruta在这个场景的应用：下一代数据中心架构-3：从视频会议应用谈起 ，这样的场景对于抖音或者淘宝这样的直播带货的场景非常有用，当然也对思科Webex/Zoom/钉钉这一类的会议系统用处非常大。

那么问题来了，如果使用SRv6如何做到每个用户精细化的定义SR-Policy，如何更改？那么势必要给应用赋予特权才能操作IPv6 Option Header，同时终端还需要支持全链路IPv6. 各自退一步，放在UDP header里面不就好了么？应用侧也可以玩，网络侧也可以解析，大家一起好好玩~

最后也就是常见的广域网优化，网络的拥塞在哪？通常在运营商互联的边界上，而公有云有大量的和其他运营商互联的连接，那么网络供给侧改革的另一步就是云网的协同上，所以这也是Ruta可以解决的问题：Ruta for Telemetry

各个运营商，各个云和各个大厂，咱们一起来玩一把大的？应用的更改其实非常容易，App通常一个月几个版本，服务器端简单的做一个QUIC-TCP的Sidecar就能非常容易的实现Ruta. 网络设备通常只需要在一些关键节点用BPF写一个软的forwarder，或者用FPGA做个智能网卡，或者真有钱Barefoot/Silicon one的片子写几行代码就能实现。

是时候进行供给侧改革了，虽然会短痛，总比等到有一天应用全做完了吃掉你好吧？