为什么不需要SRv6

SDNAB转发了一篇<为什么需要SRv6?>，评论区几乎全是<为什么不需要SRv6>.估计全世界能写，敢写，并且有替代解的除了渣以外寥寥无几。

首先声明此文代表作者个人观点，与任职企业无关。其次声明完全拥护党和国家IPv6的演进战略，只是反对利用SRv6在IPv6过度的过程中混淆概念。第三，明显发现SRv6的技术缺陷，国外的大佬和专家也有犯错的时候，为了避免国家损失诚意提醒

SRv6技术有价值么？

前面的文章中谈到三点：

1. 智慧

SRv6具有强大的可编程能力么？编程语义图灵完备么？基于数据包的语义处理必定会缺失计算的上下文， 很简单的一个场景。我们需要可编程去处理某个HTTP请求，中间要绕行某个Service-Chain的节点做HTTP的安全性检查。防火墙则必须把所有的这个HTTP请求的多个数据包缓存起来并且还要额外缓存每个包的SRv6栈。怎么说呢，相当于原来防火墙基于整个HTTP请求存一份栈就好，现在你要把它变成每个数据包存一份。

一个不恰当的比喻就是人家都在玩协程更加轻量化上下文的时候，你偏要人家玩多进程？你栈空间多到爆了？

所以SRv6在可编程能力上，只能说这群做网络的人根本不懂什么叫编程，特别是在某司ppt上看到下面一句话

SR for Anything, Network as a Computer

我差点笑翻了，果然没编过程序写过代码的人什么都敢吹…你们这种搞网络的提出这话和直男对妹子说：”多喝热水“没有区别…

至于第二点, 原文说：SRv6完全基于SDN架构，可以跨越APP和网络之间的鸿沟，将APP的应用程序信息带入到网络中，可以基于全局信息进行网络调度和优化。

那么请问如何让一个APP在用户态不通过Kernel，不需要Root权限去修改IPv6 Option header？或者简单的说，你如何让苹果安卓和windows很快的在用户态实现？即便可以，人家应用辛辛苦苦Kernel Bypass提高性能，你把人家往Kernel里赶几个意思？

问题的关键就在于SRv6的封装在IPv6上，又不想侵入应用层，同时标准上又要与RFC8663 MPLS-SR over UDP区分，于是设计了一个很丑的IPv6 Option header的方案

2.极简

此处又混淆了是非，MPLS-SR一开始不就是取消了LDP/RSVP-TE么？SRv6对应的比较应该是MPLS-SR。至于跨域就是一个笑话，SRv6在域间有uRPF机制时如何玩？

3.纯IP化

SRv6只支持IPv6， 如何在IPv4大量部署的情况下构建NAT可穿越、4to6融合的架构？想起十多年前我们和李星教授一起实现IVI的时候，其实很多时候并不是Overlay能够解决的，xlate也是需要的。

SRv6的问题

网络为主的思维，运营商为主的视角

在网络虚拟化的过程中，其实诞生了很多协议，而SRv6的诞生更多的是从运营商的视角来看的，毕竟Clarence也不太懂企业网BU和数据中心BU，事实上我们来看整个演进的过程：

园区网更多的考虑的是移动终端身份鉴别和位置无关(Location-agnostic)的策略一致性，所以它是一个以用户为中心(User-Centric)设计的虚拟化协议栈. 数据中心及一些容器网络则更多的考虑的是以应用为中心(Application-Centric)的场景，而中间的SDWAN被逼的脑裂，只能玩一些传输无关(Transport-agnostic)的以传输为中心的场景。

SRv6源自于MPLS-SR，解决的只是运营商网络中的快速收敛TI-LFA和流量工程的问题， MPLS-SR本身是一个非常好的技术， 栈在包头，对于所有设备处理都非常容易。而SRv6明显让几家可编程的交换机芯片厂商都带来了很大的压力。

同时在场景上的缺失，也是一个问题。SRv6一开始只改目的地址的行为就会带来中间某个节点由于uRPF的检查而使得流量工程策略失效，这是一个安全性问题的硬伤

其实现在和很多运营商客户交流下来也存在一个问题：你说SRv6能提供SLA保障，可编程灵活性，难道这些MPLS-SR就不能提供了么？唯一的难题是在最后一公里还有大量IPv4的陈旧设备的场景下，如何接入运营商骨干网的能力，以及如何让应用很容易的调度骨干网资源的问题。

应用的融合问题

SRv6并没有给应用提供链路状态的服务，让应用如何在Userspace里直观的编程。敲黑板啊，Service Provider的本质是提供服务不是夺权，算力网络算的是什么？作为一个服务提供商你应该更好的了解客户的应用，流式数据处理框架、计算范式的变革，边缘算力如何融合，应用如何方便调度。例如下图：

怎么能够让应用终端实现多归属，并识别拥塞自主算路。很多时候运营商总是越俎代庖，总把自己当成交通警察而不是路政服务人员。你老老实实的建好高速公路，然后构建一个更好的ETC付费场景不是更好么？把资源分享出来并灵活收费才是出路~

SID太长的问题

IPv6本身就是在当年Over Engineering了一个128bits的地址，导致很多器件做路由查询代价特别大。而通常在地址编址的过程中又有基于地理位置编址省路由表LPM查询空间或者基于策略编址省ACL ExactlyMatch表项的取舍。而SRv6最大的缺陷就是128bits的SID，但是最终没有意识到问题的严重性，反而采用打补丁的方式，uSID或者gSID其实对于超高速的转发芯片都带来了极大的复杂度。

出路:Ruta

《云原生路由架构探索》

论文地址:https://arxiv.org/abs/2112.08686

正是因为这些原因，才会诞生Ruta这样的技术，而Ruta出来收到的来自各个大厂RTC部门的关注远大于网络，更加贴近应用使得它的服务能力远高于SRv6.

首先它是一个User space的协议，任何应用可以在其UDP Payload里随意的指定自己的转发路径和中继节点，提供了极大的灵活性，同时正是因为它在Layer4，实现了底层MPLS、IPv4、IPv6混传的支持能力，为IPv4和IPv6以及运营商已有MPLS网络融合提供了天然的利旧保障能力

其次，它的路由控制面更加开放，传统的IGP、BGP对于应用协议接入非常困难，而Ruta一开始就选择了ETCD做为路由、密钥、策略的全网强一致性的分布式KV服务，应用接入容易，并且以全云原生的架构构建，弹性扩容能力强.针对大容量的部署场景，我们还发现路由和策略需要强一致性，而链路状态协议只需要最终一致性，因此我们还构建了基于Region的Redis和跨区Gossip的传输方式。

最本质的区别在于让应用能够看到整个网络的链路状态，让应用选路。而且整个SID只有48bits，并不需要复杂的压缩流程，应用编址也非常直观。

接下来我们准备和一些运营商及RTC厂商一起对接完成一个更加开放的生态环境，这才是出路。以应用和数据为中心，网络只是计算的一部分，而不是 Network as a computer.