摘要

  • IETF LSR 工作组 9 月 29 日发布的 L2 聚合成员远端标识草案第 07 版，要求路由器通告的远端 ID 与邻居为同一成员通告的非零 32 位本地 ID 完全一致。上一版曾建议直接使用 LLDP 的端口 ID。该文仍处于 IESG Last Call，并非 RFC。
  • 新稿说明，LLDP 与 LACP 能辅助识别邻居端口，但其端口编号不必等于路由通告使用的成员标识。即使 IGP 报文通过认证，也不能由此证明本地发现或配置得到的线缆配对正确。

链路聚合把多条物理成员呈现为一条逻辑链路。对普通转发而言，知道逻辑链路存在可能已经够用；对逐成员的流量工程或故障定位而言，控制器还要知道甲端的哪一个成员接到乙端的哪一个成员。IETF 的《Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members》正试图让 OSPF、IS-IS 及 BGP-LS 传递这层细节。9 月 29 日的第 07 版没有宣称网络已经实现了这项能力，而是把通告内容应当依据什么，写得更严格。

变化集中在“取得远端标识”的环节。8 月 22 日的第 06 版推荐通过 LLDP 取得邻居端口 ID，并建议把它用于远端接口标识的通告；LACP 端口编号则被列为另一种可能来源。第 07 版撤去了这种直接代入。两端各自为聚合成员分配非零的 32 位本地标识。甲端通告成员 A 的远端 ID 时，数值必须精确等于乙端为对应成员通告的本地 ID；反过来也一样。控制器由此才能核对一对成员，而不是仅靠看起来相似的端口名称猜测配对。

为什么端口发现不够？LLDP 的 Port ID 取决于所用子类型，不一定是 32 位数值；LACP 的 Actor 和 Partner 端口号只有 16 位，而且由链路两端独立赋值。它们可以告诉设备邻居端口是谁，却不自动交付邻居在路由属性中声明的那个数字。新稿允许配置或实现自行设计发现程序，但明确把精确值的获取排除在草案规定范围之外。这里不是禁用 LLDP 或 LACP，而是要求实现者承担从发现信息到正式成员 ID 的映射和核验。

设想一条尚未核实的成员线：甲端通过发现报文看见一个端口名，软件却把该名字或另一个局部编号错当成乙端的成员 ID。随后甲端发出的 IGP 通告即使经过认证，也只是证实“甲端确实发了这项断言”。它无法证实该断言所依据的二层信息没有被误配、过期或伪造。第 07 版新增的安全讨论把这一点称为信任边界：错误配对可能误导控制器选择成员路径，也可能让故障范围判断失准。草案陈述的是风险机制，并没有报告任何真实运营商事故。

新稿也处理了容易被误读的空值。缺少远端 ID 表示尚未学到或没有通告，不表示对端根本没有该成员；一侧部署新扩展、另一侧尚未部署时尤其如此。IS-IS 的有序清单可用零作为“未知”占位，传给 BGP-LS 时不能把零当成有效远端 ID。BGP-LS 传播者不负责语义核验，消费它的控制器仍需检查两端数值是否相互对应。若把“未知”写成“无链路”，部分部署就会变成错误的拓扑结论。

Datatracker 当前把第 07 版列为活跃 Internet-Draft，处于至 10 月 13 日结束的 IESG Last Call，目标状态是 Proposed Standard。它不是已获批准的 RFC，文字仍可能变。按指定链路开启通告而非默认开启的要求上一版已经存在；这一轮真正收紧的是启用之后，那个远端数字凭什么值得控制器相信。

资料来源