摘要

  • RFC 10067 把两条方向相反、各自独立的 Segment Routing 路径关联起来，让两端知道回程怎样走。关联记录不会把它们变成一条天然双向的路。
  • 协议要求双方先声明支持关联类型 8，各端分别报告路径标识。真正的双向可用性，还要靠两端的运行状态和两个方向的测量合在一起判断。

去程买了票，回程还得查车次

业务界面喜欢画一根线：甲地连着乙地。实际转发有两趟车。去程走一条 Segment Routing 路径，回程可以走另一条；知道去程怎么走的节点，未必知道回程的路线。RFC 10067 为 PCEP 增加了一种办法，把两条单向 SR LSP 编成一个双向关联。控制器发起或端点发起都可以。协议关联的是两条路，并没有把路面焊在一起。

两端各有自己的 PLSP-ID。起点报告它发出的路径，另一端报告反向路径；路径计算单元 PCE 保存两个标识。RFC 9059 曾为 RSVP-TE 路径规定类似的成对关系，RFC 10067 把对象换成 SR 与 SRv6。一个共同的关联号，像把两张工单夹在一起的回形针。它能帮助人找记录，不能证明两辆车都跑到了终点。

这个“回程工单”有实际用途。起点要使用定向 BFD 或性能测量时，需要知道反向 SR 路径；规范分别指向 RFC 9612 与 RFC 9503。有了回程描述，设备才知道检查什么。但两个方向的存活检测仍是独立的。RFC 10067 要求管理层把两侧监测结果关联起来，才能判断双向业务是否运行。只看一侧绿灯，等于听见“我出发了”就宣布对话完成。

成对之前，先核对身份证

两台 PCEP 对等设备必须在开场消息里互相声明支持关联类型 8，之后才可使用该关联。RFC 8697 给出通用关联机制。同一台 PCE 上，一条 SR LSP 不得同时属于两组双向 SR 关联。出现这种情况时，PCE 不应向入口节点发送反向路线，还要记日志、发告警。这不是挑剔格式，而是在阻止同一趟车拿到两张相互冲突的返程票。

PCE 用 PATH-ATTRIB 中的反向标记发送回程显式路线；多路径的编码来自 RFC 10066。另一个标志可说明两个方向是否共路。如果它与反向路线属性互相矛盾，PCC 必须记录错误并告警。旧的“Reverse LSP”标志在这里不能用，因为这套 SR 关联并没有按旧模型实例化那种反向 LSP。名字看着相似，机制并不相同。

变更单至少应留下双方能力声明、关联号、两个 PLSP-ID、两端报告的路由、反向路由下发记录，以及两个方向的测量。更新前后的版本都要留。故障发生时，值班工程师需要的是“哪一端还知道怎么回来”，不是会议上画得最顺眼的线。

恒路关于运行代码优先的判断，在这里是一把编辑尺：控制面的标签要由实际运行来兑现。RFC 10067 定义信号与告警；网络经营者决定证据何时足以支撑“这条双向业务可用”的对外说法。客户不会给关联号付款，他们要的是回应。