SRv6/P4/SDWAN都错了：一些看似离经叛道的苦口良药

另一方面
你们看看这些技术，商用了多少，已经商用的遇到了多少问题，摇旗呐喊的只会说好话讲故事的一般都是卖芯片的厂家，真正用的呢？
有一个灵魂的拷问：

有些话很难听，良药苦口利于病，请您别急着摔手机，耐心看完，你不得不承认，SRv6只在运营商玩，企业落地只有少数的商用案例，更不要说和应用融合了。P4只能几个大的数据中心用，真的落地的有几个？所有SDWAN的vendor急吼吼的说我们在升级成SASE，看看gartner的HypeCycle你就明白原因了，就是缩短债务久期的谎言罢了，估计过段时间还要说自己是SDP跟做安全的抢生意（软件定义的边界）

1.SRv6怎么错了

SDN的关键是给应用可编程能力，可无论哪家怎么弄，SRv6的最大问题在哪？非得塞盒子赚钱啊，然后变成了
SRv6的网络建设好了，却反过来到处找应用场景，然后生搬硬套弄一些可编程的SRH，应用买单么？被抱怨Header太长又搞uSID/cSID，想着自己编码方便完全不顾及应用。最终应用无可奈何自己去搞ServiceMesh和Sidecar去了，同时容器先用Linux搞Veth-pair/iptables替代TOR，然后可编程的CDN和UDP pinghole来构建多转发路径，抖音这样的视频直播业务只能在边缘自己做编解码和自研源路由协议的随路转发，本来可以用网络的SBC，但是网络可编程能力不行，SRv6带transcoding function 么，连SDP描述都没有，这些跟网络没啥关系了，最终纯软件性能差了宁愿用BPF也不鸟你网络的可编程性？实在是不行了自己做SmartNIC也不要交换机编程。问题在哪？做网络的人说SRv6 Linux 也支持啊，你要知道多少设备要升级Kernel，特别是各个运营商放到大家家里的光猫，然后多少应用的码农要去瞎折腾你那个Option header，至于可编程也就是做网络的人自娱自乐罢了，End.XXX也都是一些packet processing的原语，跟应用一点关系都没有。放开点，各自退一步好好弄好传输层和传输层的可编程能力。
《网络服务化与供给侧改革：退一步海阔天空》
所以我在设计QUIC-SR/Ruta的时候，第一点就是要满足应用层直接改socket参数就可以设置转发路径和转发规则了,能userspace搞定的事情，别麻烦别人。
当然能利用硬件的能力也要多用，这个后面在讲P4的时候说。

 session, err := quic.DialAddr(*remoteSock, tlsConf, config) apptoken:=[]byte{0x1, 0x2, 0x3} srlist:=[]string{1.1.1.1:2345,2.2.2.2:4567，255.vnid:end.DT4} session.SetQUICSR(srlist,apptoken)

2.P4怎么错了

P4也是从14年左右出来到现在落地的有几家？除了搞点科研的场景，P4的错在哪？一开始就是以可编程交换机硬件为导向设计的一个语言，包括后来某家的NPL。交换机的业务模型简单，PISA的做法没有什么不妥，但是到了后来越来越复杂了，需要支持的平台越来越多了，于是出现一个荒唐的事情，有人要把P4编译成BPF执行。

而P4语言本身由于pipeline的模型限制和命令式编程语法，导致它根本无法进行其它的处理，例如SDWAN的场景，你见过有谁能用P4搞定的？

写过P4的人都知道，模块化能力几乎也为零，很多时候pipeline决定了一些模块复用和branch/jmp无法实现。
然后到架构选择的时候，总是Pipeline快，RTC慢，Pipeline Recycle性能下降厉害，RTC基于流hash的无法处理elephant flow，单核IPC性能差。其实成年人的世界从来没有选择题，都要！软硬件一体化才是最根本的解决方案，哪些适合RTC的，哪些适合pipeline的，
如何把数据包编码使得转发模型能够更好适应异构的硬件平台，编码上降低RTC-Pipeline-RTC这样的复杂切换流程，设计一种完备的DSL并且可以同时支持流量的RTC/Pipeline offload，这才是关键。

3.SDWAN怎么错了

SDWAN的问题已经说了很多遍了，
一个Leader和Niche Players象限挤满了的行业出了什么问题？是技术对了而市场没有成熟？如果是这样，应该看到大量的visionaries。但偏偏不是，那就是市场对了，而技术本身错了？第一象限里的每一家我都可以给你吐槽一整天它们的各种技术缺陷。

原因很简单，简单到所有的人都忽视了，就像当年的Nokia，什么都没做错最后还是死了。
所有的人谈到安全隧道就是IPsec，却不知道IKE交互需要大量的计算资源，其实有更好的办法可以避免。例如TLS的0-RTT
所有的人谈到路由协议，因为SPF一个domain算最多容纳2000个节点，容量不满足需求，而本来就是一个大网上万个路由器的部署， 用点BGP也没错啊。你看就连Calico这种家伙都要来玩BGP.其实就是一个overlay的Key Value Mapping做一致性。
所有的人谈到编排就上Yang Model/netconf,殊不知广域网线路的不可靠性和高延迟使得整个Programming的过程中有大量的Side effect，和局域网DC/Campus有极大的不同，然后Controller 容量就有问题了。

所有的人谈到Telemetry和Linkstate采集，就是Yang Telemetry+ BGP LinkState，却没有动脑是否应该在设备上做聚合和归因分析，完了报结果就好了？

本质上SDWAN就是一个安全的Overlay，数据中心都HostOverlay了，我相信移动端的host overlay和App容器化的场景也不远了。到时候人家都是sidecar随便弄个udp socket自己玩就好了，没你SDWAN什么事了。
构建Transparency VPC才是王道。

3.什么是对的？

十多年前，阿里说要把云计算做的像用水，用电那么方便，现在呢？短板在网络。如今华为也提出云是第四次工业革命，要把云网的算力和智能输送到企业和个人，如同电网把电力输送到千家万户。这么大一个场景，为什么就不能好好的研究一下应用，迁就一下应用呢？说好的可编程能力，连简单的编程范式都搞不清楚，把云的资源想的太完美或者太不完美，把FPGA的能力想的太强或者太弱，有机的结合这一系列的东西设计编程范式和编码方法才是出路啊。Functional Programming with Declarative API才是很多并行和分布式计算的关键。

而对于网络，接受自己2/3层的不完美，在4层上和应用协同才是关键，而自己抱着SRv6/P4/SDWAN不放手，就等着应用有一天告诉你，你把线连通了就行了，我网卡都做了，别的没你什么事了。。。对的，我在开始做网卡了，Ruta的硬件加速。

 当然还有另外一个项目，一个分布式的AI流计算边缘计算集群，用于构建一个车联网的随路计算框架，买了一堆树莓派构建ARM集群，边缘的解决方案，nVidia的Jetson GPU太重了，编程麻烦，而Xilinx的FPGA太烦了，大量的底层开发即便有Vitis AI也觉得不舒服。ARM新的Neoverse N2带上了SVE2看上去就优雅很多了。软硬件结合的最大关键是，别给应用找麻烦。