我们常说，Segment Routing（SR）的出现就是为了替代MPLS。但MPLS技术的本身也是为了优化网络和减少路由表的大小而发明的，那出现了什么问题，导致了SR技术的出现？而SR技术发展到现在，热度是减少了不少，但也出现了不少问题！
我们先从MPLS说起。
作为一种传输技术，但MPLS实际上已经非常出色了。尽管SD-WAN供应商等进行了一些反对MPLS的营销，但在SR技术出现之前，MPLS在传输技术上并没有真正的替代品。
MPLS提供了低开销的服务底层，只有PE路由器（Provider Edge, PE）需要为L3VPN传输完整的Internet路由表和虚拟路由转发（Virtual Routing and Forwarding, VRF）。
MPLS的流量工程能够实现在任何拓扑中均匀地对流量进行负载均衡，为需要它的服务提供低延迟路径以及不相交的路径等。此外，MPLS的快速重新路由功能可在链路/节点故障后实现低于50ms的收敛。
图：传统MPLS协议
但是，MPLS在发展过程中变得复杂。传统MPLS网络通常运行IS-IS或OSPF进行IP路由，运行标签分发协议（Label Distribution Protocol, LDP）或资源预留协议（Resource Reservation Protocol, RSVP）进行标签分配，以及边界网关协议（Border Gateway Protocol, BGP）及其多种地址族用于MPLS服务。
这种传统MPLS堆栈存在三个问题：操作复杂性、协议限制和互操作性问题。
加微信“OFC2025”，进传输专业群，相关阅读：
操作复杂性方面，LDP配置和操作相对简单，但不支持流量工程，对使用远程链路保护的快速重新路由支持有限。RSVP虽然支持流量工程，但需要点对点隧道网格，限制了可扩展性。
但在实际部署的时候，“LDP或RSVP”通常又变成“LDP和RSVP”。每个 PoP 中的 LDP 和连接不同PoP的WAN链路上的RSVP，以及通过 RSVP 链路进行目标 LDP 会话。增加了操作的复杂性。
图：LDP会话
在协议限制方面，RSVP并不支持等价多路径（ECMP）功能，而LDP虽然提供了对ECMP的支持，却可能面临某些限制。至于LDP与IGP的同步机制，其设计初衷是为了避免在网络收敛过程中产生流量黑洞，但这一机制有时反而会引发问题，导致IGP会话陷入僵局，这无疑是一种弄巧成拙的局面。
此外，当采用RSVP进行流量工程时，结果往往难以预测。这是因为每个路由器都是独立地向其标签交换路径（LSP）发送信号，而路由的最终状态实际上取决于这些信号发送的顺序，这种不确定性给网络的稳定性和预测性带来了挑战。
同时，具有讽刺意味的是，独立LSP信令并不等同于可扩展性的提升。实际上，每个路由器都需要维护一份关于所有经过它的传输LSP的状态记录，这反而限制了RSVP的扩展能力。
互操作性问题方面，由于MPLS网络至少包含三个协议及其多种扩展，使用不同供应商的硬件构建MPLS网络可能会遇到问题，在传统的 MPLS 架构中，这通常意味着如果一个路由器不支持某个功能，我们就不能使用它。并非所有实现都支持所有功能和扩展，不同供应商对RFC的解释可能不同，导致即使声称支持某个标准，硬件连接后也可能无法正常工作。
与传统网络技术不同的是，SR它摒弃了传统的标签分发机制，通过向IS-IS和OSPF添加扩展，通告分段ID（Segment Identifier, SID）以及链路和前缀信息，不再有“标签切换”。入口 LER 只是将出口 LER 的 SID 推送到数据包上，所有中转 LSR 都不会更改该标签（至少在理论上，实际实施仍会使用相同的标签交换标签）。
另外，SR基于IP，没有RSVP那样的电路交换，本身就支持ECMP和任播，具有良好的扩展性。
使用SR进行流量工程时，与RSVP不同，SR不会向LSP发出信号，而是通过添加多个SID来沿流量工程路径转发数据包。SR的无状态特性意味着正确的流量工程需要一个控制器。没有控制器，就无法使用带宽预留，虽然可以使用约束最短路径优先（Constrained Shortest Path First, CSPF）进行流量工程，但这需要路由器上的额外功能。
在上图所示的拓扑中，为了通过蓝色链路将数据包从 R1 转发到 R6，R1 会推送三个标签：
- R3 的节点 SID -> 使用最短路径将数据包转发到 R3。
- R3 到 R5 的邻接 SID （Adj-SID） > 使用该特定链路。
- R6 的节点 SID -> 将数据包传送到实际目的地 （R6）。
但存在这样一个问题：SR作为一种无状态的协议，其流量工程的实现依赖于控制器的存在。缺少控制器的支持，带宽预留变得不可行。即便可以依赖于路由器上的关联或显式路径来实施约束最短路径优先（CSPF）策略，这种替代方案也会因需要路由器具备额外的功能而变得复杂，增加了部署的难度。
SR降低了MPLS的门槛，使得路由器上的SR实现非常简单。IGP扩展用于通告SRGB、SRLB、前缀和调整SID，BGP-LS将链路状态拓扑通告给SR控制器，BGP-SRTE或PCEP用于从控制器接收SR-TE策略。
实现SR的基本要求仅仅是在IS-IS协议中增加几个新的类型长度值（TLV）。完成这一步骤后，我们可以利用来自不同供应商的路由器，将IGP拓扑信息导出至BGP链路状态（BGP-LS）。至于那些不支持BGP段路由传输（BGP-SRTE）或路径计算元素通信协议（PCEP）的路由器，传统的BGP标签分发（BGP-LU）提供了一个有效的解决方案，用以接收和实施路由策略。
SR的互操作性问题风险较低，因为没有RSVP信令，也没有LDP-IGP同步。主要的互操作性问题可能只发生在IGP级别。也许唯一烦人的是 SRGB ：每个供应商都决定使用不同的默认范围，但我们可以在需要时更改它。
SR还使得混合方法变得可行，即在网络核心使用大型供应商的硬件，而在汇聚层和接入层可以使用更便宜的设备。
我们知道，尽管SR起源于Cisco，但它是一个开放标准，允许任何人部署。然而，大型供应商通过提出“Best Practice”设计，使用PCEP及其多种扩展，以及过度设计的控制器，试图使用户只能使用他们的SR来部署。
SR-TE控制器本质上是一台路由器，它扩展了功能以支持BGP链路状态（BGP-LS）的处理和基于约束最短路径优先（CSPF）的策略计算。由于省去了LSP信令的复杂性，SR-TE控制器的部署和操作应当比传统的MPLS流量工程（MPLS-TE）更为简便。
这种过度设计集成了多种功能，如网络监控、自动化、NetFlow收集和OSS/BSS功能，然而运行这些控制器软件需要强大的计算能力，但在路由器平台的应用场景中，这些高级功能是否真正必要呢？
现在，很多厂家都在推销复杂协议和过度设计的控制器。那为什么会出现这样的情况？
我想这主要是基于商业方面的原因，这个是希望将运营商捆绑在自家产品上，要非常容易部署带这些扩展功能的SR，迫使运营商必须用同一厂家的。另一个原因是如果控制器的部署和操作过程过于复杂，网络运营商可能就不得不向厂家购买培训服务。
SR的设计初衷是简化网络设计，而不是使其变得复杂。供应商应该提供易于部署、配置和操作的SR-TE控制器，支持基本路由器功能，并且轻量级。控制器应该专注于路由策略的计算，而不是尝试成为网络管理平台。
最后，我们引用《Segment Routing， Part 1》一书中的一段话：
…the always-on RSVP-TE full-mesh model is way too complex because it creates continuous pain for no gain as, in most of the cases, the network is just fine routing along the IGP shortest-path. A tactical TE approach is more appealing. Remember the analogy of the raincoat. One should only need to wear the raincoat when it actually rains.
Segment Routing, Part 1
那么，SR 也会搬起石头砸自己的脚，最终弄巧成拙吗？