摘要

  • 9 月 28 日更新的 draft-ietf-spring-stamp-srpm-mpls-09 将反射器的回包规则拆成普通 SR-MPLS 路径、L3 服务和 L2 服务三个场景，不再用一句笼统的“反向沿同一路径返回”概括。
  • 普通路径未收到指定回程段列表且无法选择本地 SR-MPLS 回程时，可以用 IP 转发回包；L2、L3 服务若找不到对应的反向服务，则必须丢弃测试包，不得回包。

运维屏幕上出现一次 STAMP 往返时延，并不自动意味着去程与回程都经过被考核的 SR-MPLS 服务路径。新的草案文字提出一个尤其值得单独标注的情形：反射器接到了普通 SR-MPLS 路径上的探测包，却选不出反向 SR-MPLS 路径，最后通过 IP 转发送回结果。往返交换是真实的，回程证据却已经换了性质。

本次改动可以在两个版本的原文中直接核对。第 08 版的第 6.3 节较宽泛地说，反射器沿同一 SR-MPLS 路径的反向发送测试包。第 09 版改设 6.3.1 至 6.3.3 三节，逐一说明普通路径、L3 服务和 L2 服务怎样决定回程。这是 Internet-Draft 文本的变化，不是某运营网已部署新行为的报告，更不是事故披露。

普通 SR-MPLS 路径首先看 Return Path TLV 中有无 Segment List 子 TLV。有就按指定段列表构造反向 SR-MPLS 标签栈；没有就采用反射器本地选定的反向 SR-MPLS 路径；本地仍选不出时，第 6.3.1 节才允许用 IP 转发图 10 所示的回复。这个条件不能偷换成“显式指定的回程不可用也可悄悄改走 IP”。RFC 9503 对无法使用所请求回程有单独规定。

叠加服务不享有同样的普通路径兜底。L3 场景要求从去程收到的 L3VPN 标签找到相应反向 L3 服务标签栈，还要求测试包的源地址在该 L3VPN 关联的 IPv4 或 IPv6 表中可达。找不到对应反向 L3 服务，反射器必须丢弃且不发送回复。L2 场景也必须找到与去程 L2VPN 标签相应的反向 L2 服务标签栈；找不到就丢弃、不回复。一个通过普通 IP 路由返回的包，不能被记为客户 L2 或 L3 服务回程已经得到验证。

因此，“有回复”和“无回复”都需要附带上下文。有回复可能只是找到了 IP 退路；无回复也可能是探测包已抵达反射器，但其服务回程不存在，不能直接判为去程丢包。这里讨论的是双向测量中的反射器回复。草案第 7 节明确说，单向测量不发送反射器测试包，第 6.3 节的回包封装规则不适用。

IETF Datatracker 仍将该文件列为 SPRING 工作组 Internet-Draft，状态为 I-D Exists，预期类型为 Informational。它不是 RFC，也没有给出设备互通或实际网络的测量结果。当前真正可执行的编辑判断，是要求每个指标说明自己究竟观察到了哪个回程环境。

资料