摘要

  • RFC 9104 为 Extended Administrative Group 定义了 BGP-LS Link Attribute TLV 1173。长度合法、位图完好，只能证明信息按规定被携带，不能证明消费端使用了运营方预期的颜色词典或路径策略。
  • 可审计的链条必须继续追踪 IGP 来源、BGP-LS 编码、AG/EAG 一致性、消费端词典、策略版本、计算结果、安装回执和报文观测，而不能让其中一个绿色状态代表全部环节。

一个合法字段抵达一台尚未作出决定的机器

设想一台 BGP-LS consumer 收到一条 Link NLRI。与它相伴的 Link Attribute 内有一个类型 1173 的 TLV，值长八个字节，解析器顺利读出两个 32 位 bitmask。会话正常，长度是四的倍数，属性没有触发 malformed 处置。

此时最容易说得过头的一句话是：“控制器已经知道这条链路的颜色。”这句话把若干互不等同的动作揉成了一个结论：producer 携带了位图；consumer 接受了数据结构；本地词典也许把置位映射成运营含义；某个策略也许引用这些含义；计算引擎也许生成并选中路径；执行系统也许安装结果；真实报文也许按该结果转发。

RFC 9104 负责其中最前面的一段。它在 2021 年 8 月以 Standards Track RFC 发布，规定如何通过 BGP Link-State 广告链路的 Extended Administrative Group（EAG）。它给 EAG 分配 Link Attribute TLV 类型 1173，其 Value 由一个或多个 32 位 bitmask 组成，Length 表示 Value 的字节数，并且必须是四的倍数。

这一格式有意保持简洁。它足以保存位图，却不是颜色词典、策略语言、路径计算请求，也不是转发表或服务结果的回执。

超过 32 个颜色之后，语义仍然是本地的

原有 Administrative Group 是固定 32 位掩码。工程实践常把每一位称为一种“颜色”，但颜色只是便于交谈的名字，并非互联网范围内统一的语义。某个网络里的第 12 位可以表示低时延，另一个网络可以把同一位留空，或赋予维护、合规区域等完全不同的含义。

RFC 7308 引入 EAG，让可表达的行政组不再止于 32 位。它仍由 32 位字组成，实际可携带的规模也受具体协议和介质约束，并不意味着无限扩展。RFC 9104 的作用，是给这个 IGP 链路属性一条进入 BGP-LS 的标准化路径。

新字段没有取代旧字段。RFC 9104 明确允许 TLV 1088 的 Administrative Group 与 TLV 1173 的 EAG 共存。按照 RFC 7308，如果同一链路同时广告两者，EAG 的前 32 位必须与 AG 相同；接收节点用 AG 表示 0 至 31 位，用 EAG 表示第 32 位及以上，不一致时应向运营者报告。

这条规则能帮助兼容和诊断，却仍不是业务语义证明。两个位图完全一致，也可能同时被一个过时的词典解释错。

句法错误有明确后果，语义判断另有责任人

RFC 9104 对句法边界说得很清楚：TLV 1173 的长度若不是四的倍数，就属于 malformed。出现该 TLV 的句法错误时，相关 BGP-LS Attribute 要按照错误处理规则被丢弃。解析器在这一层可以给出确定结论。

语义和内容检查属于另一层。位值是否合理、TLV 是否与适当的 NLRI 类型或 BGP-LS Attribute 关联，以及应用遇到异常内容后如何处置，都交给 BGP-LS consumer——应用或控制器。RFC 9104 也明确把 consumer behavior 放在范围之外。

因此，解析成功只能证明一组位抵达，不能推导出第 42 位仍然表示“维护期间避让”，不能证明引用它的策略已启用，也不能证明系统面对未知位时选择忽略、报警还是拒绝。

后来取代 RFC 7752 的 RFC 9552 对今天的 BGP-LS 分发模型作了更完整的说明：topology 和 traffic-engineering information 从 LSDB 或 TED 被送到外部 consumer；单个 TLV 可以定义 permissible values 和 semantics 供语义校验，而具体应用的错误处理仍可能超出协议规范范围。该文件发表于 2023 年，可用来解释当前架构，却不能倒写成某台 2021 年控制器已经正确工作的证据。

TLV 1173 里没有运营方的颜色词典

从字段结构可以直接看见它没有携带什么。TLV 1173 有长度和 bitmask，没有“第 17 位代表低时延”这样的标签，也没有词典版本、策略优先级、批准人、候选路径、选中路径、FIB 状态或报文观测。

这是从字段定义作出的明确推论，而不是假装引用 RFC 原文。它揭示了一个常见失配：位图可以跨越团队和软件边界，语义词典却可能没有同步。IGP owner 已经启用新位，consumer 仍运行旧映射；两个 consumer 收到相同 EAG，却因未知位规则或策略优先级不同而得到不同路径；迁移期间，旧 AG 与新 EAG 表面一致，但上层政策版本并不一致。

RFC 7308 对未广告位通常按零处理，同时允许本地系统采取自己的策略。正因为留有本地空间，审计材料必须记录具体 consumer 的行为，而不能凭广告内容替它作答。

把一条过长的“成功”拆成七张回执

第一张是来源回执：IGP 实例、协议、链路身份、源 LSA 或 LSP、EAG 值和观察时间。没有 link identity 与 topology epoch，格式正确的位图仍可能属于旧状态。

第二张是投影回执：BGP-LS producer、Link NLRI descriptors、Protocol-ID、peer/session、TLV 1173 的长度与原始值。若 TLV 1088 同时存在，还要保留前 32 位比对与不一致报告。

第三张是消费回执：解析结果、语义校验、链路关联、颜色词典版本和未知位规则。“已收到”不能替代“已理解”。

第四张是策略回执：被引用或排除的位、策略版本、优先级、冲突处理、批准人与回滚权限。“已理解”不能替代“已采用”。

第五张是计算回执：输入 topology epoch、候选路径、被排除的链路、选中路径与计算时间。“已采用”不能替代“已胜出”。

第六张是执行回执：southbound transaction 以及 RIB、FIB 或 label state。“已计算”不能替代“已安装”。

第七张是服务回执：报文路径、流量和与声明相关的性能或服务结果。“已安装”不能替代“已交付”。

分开这些边界不是文书负担，而是故障定位能力。路径缺失时，团队可以查出是 attribute 被丢弃、词典过期、策略未激活、候选不可行还是安装失败，而不必事后修改前一环节的证据含义。

安全与结果都没有随位图自动转移

RFC 9104 不改变 BGP 的安全模型，并假定生成源属性的 IGP 实例采用所需的 OSPF 或 IS-IS 安全机制。看到 TLV 1173 并不能单独证明源 IGP 已认证、consumer 获得授权、策略正确或路径安全。

它也不保证 freshness。信息在 producer 侧真实且及时，并不表示 consumer 计算时仍属于同一 topology epoch。正确政策与过期拓扑结合，依然可能产出意外结果。这些是需要独立测量的运行条件，不是 TLV 声称解决的问题。

相邻 RFC 的对象也不能混入本篇。RFC 9917 针对 reverse Administrative Group 如何参与 Flex-Algorithm，包含远端测量、阈值和剪枝次序；RFC 9825 讨论 OSPF 行政标签列表的顺序与容量截断。RFC 9104 处理的是 EAG bitmask 的 BGP-LS 投影。三者的证据义务不同。

把“携带成功”说准，反而更有价值

TLV 1173 提供稳定 code point、可复现编码和明确的 malformed 处置，这让多组件系统更容易互操作，也更容易检查。限制结论并不会削弱标准的价值。

Heng Lu 的 Running-Code Primacy 可以作为披露的编辑镜头：协调工件与实际被实现、验证、部署和使用的结果不是同一层事实。Minimum Initial Specification 则提醒共同层只承载必要语义，把后续本地选择留在本地。两篇文章都不证明 RFC 作者意图或任何部署事实，但能帮助读者避免把规范字段当成运行结果。

因此，最稳妥的报告可以这样结束第一句：“这条链路的 EAG 以合法 TLV 1173 抵达 consumer。”在声称网络选择或执行了什么之前，另起一句，并拿出属于那个边界的回执。

来源