摘要

  • RFC 9703 为 PeerAdj、PeerNode、PeerSet SID 定义 Target FEC Stack 子 TLV，使远端 ASBR 能核验 AS、Router ID 与 EBGP 会话关联。
  • PeerAdj 只有在接口地址非零时才核验实际入接口；PeerNode 的多链路细节要靠 DDMAP，并由控制器另行与拓扑对账。
  • 返回码 3 是一项有边界的 FEC/出口结果，不证明控制器模型、选定链路、生产 SR Policy 或客户交付正确。

名称对上了，不代表线也对上了

控制器通过 BGP-LS 得知一个 PeerAdj SID 指向某条出口链路，并据此下发策略。MPLS traceroute 抵达邻接 ASBR，接收方的本地 AS、BGP Router ID 和 EBGP 对端关系都与 FEC 相符，最终返回“本路由器是该 FEC 的出口”。

这个结果的含义取决于接口字段。如果 PeerAdj FEC 中的远端接口地址非零，接收方还要把 OAM 包的实际入接口与之比较；不符时使用返回码 35。如果字段为零，RFC 9703 明确说应跳过入接口校验。因此，两个看起来同样绿色的结果，覆盖范围可能不同。

RFC 9703 于 2024 年 12 月作为 IETF 标准轨文档发布，为 PeerAdj、PeerNode 与 PeerSet 分配子类型 38、39、40。三者分别命名一条对等链路、可跨多条链路的节点会话，以及可能在多个对端之间分担流量的集合。对其中一种的成功，不能代替另外两种的细节。

发起端用 RFC 9086 的 BGP-LS EPE 或控制器资料构造 Target FEC Stack。RFC 9703 同时把“如何取得并携带全部构造细节”留在范围之外。FEC 是一份带来源的控制面关联声明，不是对实时数据面的自证。

PeerNode 还有另一层缺口：多跳 EBGP 会话可能在多条接口上负载分担。RFC 8029 的 DDMAP 可提供下一跳接口，控制器可以与自己的拓扑对照。但 RFC 9703 又明确指出，它定义的流程不会发现控制器状态与转发状态的差异。收到 DDMAP、执行对账、对账一致，必须是三条记录。

这也划清了 RFC 9716 的边界：RFC 9716 处理跨域诊断回应怎样返回；RFC 9703 处理前向 EPE FEC 命名了什么、远端执行了哪些校验、又有哪些观察从未发生。

证据链至少应保留：BGP-LS 声明与年龄、控制器库存版本、标签栈、FEC 原始字节、回应者身份、AS/Router ID/会话结果、接口检查的执行/跳过/失败状态、DDMAP、控制器对账、Echo 返回码，以及独立采集的生产流量和应用收件。skipped_zero_address 不能写成 pass；PeerSet 中某一成员回应，也不证明客户流量选择了它。

来源：RFC 9703、RFC Editor 记录、IETF Datatracker、RFC 9086、RFC 8029、RFC 8287、RFC 9256、RFC 8403、RFC 8690、IANA MPLS LSP Ping 注册表。公开标注的编辑框架：Running-Code Primacy、Minimum Initial Specification、现实层次。