摘要

  • RFC 7149 从服务提供商的角度指出，控制器能否被网络触达、如何引导启动以及连接丢失时如何维持服务，都是运营责任，并非分离控制面与转发面后自动获得的好处。
  • 对不运行 IGP/BGP 的网络，备忘录认为可能需要独立的引导协议或网络，并要求将其成本与接入现有路由系统的成本进行比较。若与策略决策点（PDP）的连接丢失，底层网络仍应保持运行。
  • RFC 7149 属于 Informational 文档。它提出设计视角和有条件的要求，不是互联网标准、部署普查，也没有报告真实故障。

平面分离并不是全部历史

SDN 常被简化为清晰的分工：控制面决策，转发面执行。2014 年 3 月发布的 RFC 7149 提醒读者，这种图景可能夸大了新意。路由器早已常见由软件计算路由、由硬件转发的组合。更值得关注的变化，是把决策逻辑移到一个逻辑上集中的实体，由它对网络设备进行编程。

这个变化带来了实际依赖。控制器要发现设备及其能力，交换策略与服务信息，分配资源、落实决策，并收到服务是否兑现的反馈。RFC 7149 将这些工作归为四类：拓扑和能力发现；服务暴露与参数协商；动态资源分配与策略执行；以及用于履约和保障的反馈。

因此，备忘录把网络架构与服务提供商对客户的承诺联系起来。按它提出的暂定定义，服务不只是软件选出的路径，而是一个可确定交付、参数可与客户协商的结果。这是一种分析视角，并非被普遍采纳的 SDN 定义。它把问题从“有没有控制器”转向“提供商能否呈现、交付并核验双方约定的服务”。

控制器也需要一条进入所控网络的路

引导启动让这种依赖变得具体。在不运行 IGP/BGP 的网络里，控制器可能要依靠另一套协议或网络来发现并配置设备。这样的通道需要建设、保护、运营并保持可达。把决策点接入现有路由系统，或许能省去平行的引导网络，却也会让设计受该系统的行为和边界约束。RFC 7149 要求提供商比较这些取舍，而不是假设控制应用可以凭空运行在尚未配置的网络之上。

故障场景同样关键。对于文中讨论的不运行 IGP/BGP 的环境，备忘录指出，即使与 PDP 的连接丢失，底层网络也应保持运行。这不是说所有控制器故障都会中断流量，更不是对真实事故的记述。它是一项有条件的连续性要求：既然决策点被分离，就必须说清通信中断后网络还能自主完成什么。

设备发现完成，也不代表服务已准备就绪。控制器可能已经列出设备，却尚未与客户协商参数、安装策略、确认资源或收到保障反馈。把这些环节分开，才能避免把仪表盘上的“已连接”误当成服务已经兑现。

从架构承诺到运营证据

RFC 7149 也没有把 SDN 等同于某个必选协议或一次性迁移。OpenFlow 只是工具之一；备忘录预期新方案会逐步接入现有网络，并与供应商各自的系统共存。中央决策实体不应成为单点故障，也不应降低转发性能。它们是架构上的提醒，并不能证明某个系统已经满足这些要求。

这一区分对历史叙述很重要。Informational RFC 可以组织讨论，指出运营方应回答的问题；它不能证明有多少服务商部署了这种架构、实际服务结果如何，或某次故障是否发生。要支撑这些说法，需要部署记录、测量数据、运营报告和客户结果，而不是仅凭文档获批。

RFC 7149 的持久贡献，与其说是提出了新的转发原语，不如说是改变了举证责任的位置。可编程性没有消除可达性、可观测性和回退机制的需要，而是让控制通道本身成为服务设计的一部分。在问控制器能发出哪些命令之前，提供商必须说明怎样连接到它、能够核验什么，以及回到决策点的通路消失后网络会如何运行。

来源