摘要

  • IESG 批准的新扩展允许 BGP SR Policy 候选路径携带其预期 Network Resource Partition 的控制面 NRP ID。
  • 该编号只声明域内关联，不会分配底层资源，也不能单独证明本地选择器、隔离效果、可用容量或业务结果。

数字先到，资源未必随后出现

设想 headend 收到同一颜色和端点下的两条候选路径。一条带有 NRP ID 17，另一条带有 29。对控制器而言，差异十分明确：两条路径意在调用不同的底层资源分区。

然而，更新报文中没有链路余量、队列状态、接口策略或隔离测量。它也没有说明 headend 是否选择并安装了该候选路径，是否把控制面编号映射为正确的数据面选择器，以及业务是否真的被导向相应资源。

这不是一宗已报告的网络事故，而是一个用于划定权限边界的案例。BGP 字段可以传递“应当使用哪个分区”，真正执行这一意图的动作仍分散在其他系统中。

2026 年 8 月 25 日 18:03 UTC，IETF 宣布 IESG 已批准 draft-ietf-idr-sr-policy-nrp-13，拟按 Proposed Standard 发布。这是标准进程中的重要节点，却不是最终 RFC、IANA 登记完成或生产部署的同义词。

批准之后仍有依赖链

该文档出自 Inter-Domain Routing 工作组。公告记录了围绕 TEAS 与 SPRING 依赖关系的讨论，以及推进文档的粗略共识；规范性引用的解决被留到 RFC Editor 队列中完成。

截至 8 月 28 日证据冻结时，Datatracker 仍将第 13 版标为 Active Internet-Draft。RFC Editor 状态是因未收到引用而阻塞，IANA 审查显示版本发生变化、需要重新审查，处理动作仍在进行。因此，现阶段不能声称已有最终 RFC 编号或完整登记状态。

公告称存在两项实现。IDR 的公开实现报告提到 Huawei VRP 与 H3C Comware 的相关界面，但报告仍含较旧版本的表述，也有功能项标记为 TBD。它能够证明实现工作已经发生，不能证明第 13 版的完整符合性、大规模互操作或业务网中的广泛启用。

NRP 的实体大于它的名字

RFC 9543 将 Network Resource Partition 定义为底层网络资源的一个子集以及与之配套的策略，可支持一个或多个网络切片业务。RFC 9732 则说明，在增强型 VPN 框架中，连接构造可以映射到这些资源。

这里的关键名词是资源与策略。运营者要真正配置容量和转发待遇，策略要决定如何使用这些资源，业务引流要决定哪些流量进入其中，测量结果再回答承诺是否兑现。

NRP ID 并不包含这些事实。第 13 版定义的是一个在 NRP 域内唯一的 32 位控制面标识。本域的配置与实现负责把它连接到数据面的 NRP Selector ID。它既不是全球唯一声明，也不是资源清单。

文档还特意限定了一种设计：网络使用专用、全域一致的数据面选择器。其他 NRP 选择方式可能不需要在 SR Policy 中显式携带该编号，因此不能把这项机制推广成所有 NRP 架构的共同前提。

六个八位组只解决线上的唯一表达

扩展在隧道类型为 SR Policy 的 BGP Tunnel Encapsulation Attribute 中定义 NRP ID sub-TLV。第 13 版使用类型 123，长度必须是六个八位组：一个标志位八位组、一个保留八位组和四个八位组的 NRP ID。

发送时标志和保留位均为零，接收时忽略。NRP ID 0 被保留，发送方不得使用，接收方会忽略携带零值的 sub-TLV。该元素是可选的，但每条候选路径最多只能出现一次。

若长度不是六，或同一候选路径出现重复 NRP ID sub-TLV，与 SR Policy NLRI 关联的 NRP 信息便是畸形的，接收方依据 RFC 7606 执行 treat-as-withdraw。这能阻止相互竞争的编码进入路由状态。

但该处置无法发现语义错误。一个非零编号可以完全符合格式，却被本地映射到错误的选择器；协议层接受并不意味着资源层正确。

BGP 选优只是下一段流程的入口

当候选路径在某个 NRP 中实例化，且该域采用专用选择器设计时，发起方必须带上 NRP ID sub-TLV。接收 BGP speaker 首先应用 RFC 9830 的有效性与可用性规则，普通 BGP 最佳路由算法不因该扩展而改变。

被选中的 SR Policy SAFI 最佳路由随后才交给 SR Policy Module。这个交接点值得单独记录：被 BGP 接受的路由未必成为活跃候选路径；SRPM 收到路径未必成功安装；即使安装完成，本地映射漂移仍可能让数据面使用错误选择器。

完整证据链还包括候选路径选择、segment list 安装、NRP ID 到选择器的映射版本、报文选择器写入、业务引流、队列与链路配置，以及流量实际获得的时延、丢包、吞吐和隔离结果。控制器“发送成功”最多证明某项关联在已知会话状态下被发出和接受。

故障切换不能偷偷更换资源含义

第 13 版允许同一 SR Policy 的不同候选路径关联不同 NRP，但明确称这种配置虽有效却不推荐；在正常场景中，各候选路径应保持同一 NRP 关联。

原因在切换时显现。优先级变化或故障可能激活另一条候选路径，而业务看到的策略键保持不变。如果新路径静默选择另一个资源分区，隔离、容量、成本和敏感信息暴露程度也会随之改变。

仅让所有设备重复同一个整数还不够。不同 headend 必须对它作出相同解释，数据面必须一致应用选择器，底层网络也必须存在相应资源。数字一致而映射不同，只是协调了语法，没有协调行为。

扩展状态主要落在控制器与 headend

草案指出，NRP 数量增长时，SR Policy 与候选路径的数量也可能增长，控制器与 headend 之间交换的信息量可以按比例上升。

该扩展没有改变 SR Policy 通告程序或 BGP 最佳路径算法。候选路径由相应 headend 安装，不会把同一份新增状态推给所有中转节点。这是一条重要的范围边界，却不代表运营成本为零。

控制器仍需创建和调和状态，headend 仍需接收、验证、移交并安装。监控若不区分已通告、已接受、已选中与已安装的数量，就可能在控制面显示绿色时掩盖 headend 的状态瓶颈。

可信邻居也可能传递错误含义

安全章节继承 BGP、SR Policy 与 NRP 的保护措施，同时直言本地风险：不正确的关联会损害流量隔离和资源保证。

通过认证的控制器可能发送错误 NRP ID；可信 headend 可能把正确编号映射到错误选择器；正确选择器也可能指向过时的资源配置。组件身份合法，不等于它们组合出的结果被授权。

NRP 关联还可能泄露网络意图，例如暴露关键任务或具有商业意义的资源结构。运营者必须把发送者和接收者限制为可信路由器与控制应用，并独立确认关联本身正确。

一次策略事件至少应保存：控制器身份和版本、BGP 邻居与会话、NLRI 键、候选路径来源和优先级、sub-TLV 原始字节、有效性与选优决定、SRPM 接收和选择状态、安装的 segment list、映射及版本、资源策略、业务引流、报文中观察到的选择器、队列/丢包/时延/隔离结果、撤回和回滚动作，以及连接这些步骤的时间戳。

来源