摘要

  • BGP-LS 从 IGP/TE 状态派生节点、链路和前缀对象，再按策略披露物理、抽象或混合视图；它既不是 LSDB 的逐字节副本，也不携带原始 LSA/LSP 序列号。
  • 会话正常、对象可解析、生产者冗余，都不能证明拓扑新鲜。任何自动化决策都应绑定源时点、Protocol-ID、Instance-ID、撤回、属性完整性、消费者合并规则以及最终的 FIB 与报文结果。

值班人员首先看到的是一个反常组合：IGP 已经绕开故障链路，BGP 会话没有中断，控制器的路径计算也成功返回；只有业务流量在原链路位置消失。

问题不在某一个明显错误的对象。生产者 A 仍持有 A 到 B 的半链路，生产者 B 仍持有 B 到 A 的半链路。分区使它们各自失去了完整的源可达性，却没有同时失去所有旧信息。消费者把互补的两半当成相互印证，重建出一条现实中已经不存在的完整边。

RFC 9552 专门描述了冗余生产者与不可达节点可能形成这种陈旧拓扑的情形。该文档于 2023 年 12 月发布，完全取代 RFC 7752，并吸收 RFC 9029 的更新。它给运营治理提出的核心问题不是“格式是否正确”，而是“谁有权描述拓扑，这项权力到什么时候失效”。

从 LSDB 出发，不等于把 LSDB 搬出去

BGP-LS 生产者通常从 OSPF 或 IS-IS 的链路状态数据库以及流量工程数据库获取信息，再编码为节点、链路、前缀 NLRI 与 BGP-LS Attribute。一个 BGP-LS 对象可以综合多个 LSA 或 LSP 的内容，原协议的序列号不会随对象一同输出。

因此，消费者拿到的不是源数据库镜像，而是一份派生结果。老化、清除、畸形或被源协议忽略的信息要按源协议规则处理；并非每个字段都适合披露；生产者还会执行导出策略。

差异也可能完全出于设计。RFC 9552 允许运营者披露物理拓扑，也允许披露由聚合节点和虚拟路径组成的抽象拓扑，或二者混合。更新时间同样可以受策略约束。给 ALTO 的成本视图和给路径计算单元的 TE 视图，本来就不必相同。

所以，“与物理资产不一致”不能单独构成错误判断。审计必须先找到该消费者的披露契约：允许哪些域、对象和属性，采用何种抽象，目标新鲜度是多少，数据用于什么目的。只有相对于这份契约，才能区分许可的抽象、传输损失和陈旧事实。

三种角色对应三段责任

RFC 9552 把参与者分为生产者、传播者和消费者。生产者把链路状态信息注入 BGP，通常来源于底层 IGP，也可以来源于 Direct 或 Static。传播者处理 UPDATE、执行 BGP Decision Process，并向下游传播被选中的信息。消费者是使用这些信息的应用或进程，本身不一定是 BGP speaker。

同一节点可以兼任多个角色，但证据不能因此混在一起。生产者要回答对象如何派生、以什么身份和策略发出；传播者要回答收到什么、选择什么、向哪个邻居发了什么；消费者要回答如何识别重复项、怎样合并、得到哪个时点的图，以及用它做了什么。

BGP speaker 到消费者的接口必须是单向的。消费者不得通过这条接口反向注入用于 BGP-LS 起源的信息。这条边界把“读拓扑”和“写网络”分开：控制器如果要下发变更，必须使用另一条经过身份认证、授权和审计的南向通道。

一张“IGP → BGP-LS → 控制器”的箭头图会隐藏许多独立决定：源接纳、对象派生、披露策略、BGP 选路、消费者合并、计算策略、批准和设备执行。前一环健康从来不是后一环正确的证明。

身份错误会让一个域变成两个，也会让两个域变成一个

非 VPN BGP-LS 使用 AFI 16388 / SAFI 71，VPN 链路状态使用 SAFI 72。RFC 4760 提供多协议能力协商以及 MP_REACH_NLRI、MP_UNREACH_NLRI。协商成功只证明传输面存在，不证明某条链路当前有效。

Protocol-ID 用来区分 IS-IS L1/L2、OSPFv2、OSPFv3、Direct 和 Static 等来源。八字节 BGP-LS Instance-ID 区分 IGP 实例。同一 IGP 域的所有生产者必须使用一致的 Instance-ID，不同域则必须唯一。设置错误时，消费者可能把同一网络拆成两套对象，或把两个独立域合并成一个图。

ASN、区域、路由器身份、拓扑 ID 以及节点和链路描述符继续限定对象身份。冗余生产者对可选 TLV 的选择如果不一致，也可能把同一物理对象表示成不同的 NLRI 或属性集合。

描述符一旦新增、删除或变化，NLRI 键随之变化。生产者不能只宣布新键；还必须用 MP_UNREACH 撤回旧键。否则消费者会同时保留新对象和幽灵对象。一次成功迁移必须同时提供正面和负面证据：新身份已到达，旧身份已从生产者、传播 RIB、Adj-RIB-Out 和消费者图中消失。

冗余只能提高可用性，不能自动提高事实质量

RFC 4271 的常规 BGP 决策过程可以从多份 BGP-LS 路径中选出一份。它选的是 BGP 意义上的优选路径，不是物理世界中最接近当前时刻的观察。

更隐蔽的问题发生在消费者合并阶段。两个生产者未必提交两份完整且独立的观测；它们可能各自提交互补的陈旧片段。合并算法由此创造了一项比任一来源都更强的陈述——“完整链路存在”。因此，“两个源都看到了”不能作为新鲜度结论。

新鲜度证明至少要包含：每个生产者能否到达原始节点，源 LSA/LSP 的身份和年龄，LSDB/TED 时点，BGP-LS 起源时间，选中与备选路径，预期撤回以及消费者合并状态。只看 session state 或对象总数会错过真正的断点。

RFC 9552 建议生产者撤回来自不可达起源节点的对象，除非明确的使用场景要求保留完整 LSDB 视图。这个例外不能作为无期限默认值。若业务确实需要保留，消费者必须能看到“保留且陈旧”的状态、用途和截止时间。

NLRI 还在，不代表属性被有意删除

对象身份位于 NLRI，很多性质位于 BGP-LS Attribute。按照 RFC 7606 的错误处理背景，畸形的 BGP-LS Attribute 可能被丢弃，而 NLRI 仍被保留。

这是一种需要显式呈现的损失状态。消费者不能把它解释成“链路仍在，只是没有度量”。系统至少应区分：属性按披露策略主动省略、未知 TLV 被透明保留、属性因错误被丢弃、以及确实没有定义该属性。

属性较大时还可能依赖 RFC 8654 的扩展消息能力。若不同生产者排除不同 TLV，或路径上的能力不一致，相同 NLRI 身份可能携带不同的可用证据。核验对象数量远远不够，必须比较完整属性集合及其哈希。

IANA BGP-LS 参数表 能说明代码点的正式定义和扩展状态，却不能证明某台设备正确采集了信息，更不能证明信息对应物理事实。

收到拓扑不是获得执行授权

RFC 4655 描述的 PCE 架构需要拓扑/TED 输入，RFC 7285 的 ALTO 可以消费抽象网络和成本图，RFC 8571 则定义了通过 BGP-LS 携带 IGP TE 性能指标的方法。这些规范都没有把“收到对象”变成“可以安装路径”。

一条可追溯的链应从源开始：保留 LSA/LSP 身份、协议、源节点可达性和 LSDB/TED 时点；在生产者处记录软件版本、Protocol-ID、Instance-ID、描述符、抽象策略和起源/撤回时间；在传播段记录能力、UPDATE、选中与备选路径、属性丢弃和延迟；在消费者处冻结对象集合、重复项规则、缺失属性、新鲜度和权限。

随后还要把计算路径绑定到准确的拓扑快照、约束、算法或策略版本及批准记录。最后逐级证明南向请求、设备接纳、label/FIB 安装和正反向报文探针。控制器 API 返回成功，不等于设备已执行；设备确认，不等于转发表正确；转发表存在，也不等于报文真的按预期经过。

隔离更新负载，也隔离披露权力

链路状态变化可能比普通 BGP 前缀更新频繁得多。RFC 9552 提醒其负载可能干扰普通前缀分发，并建议采用专用 route reflector 或等效隔离，同时把 BGP-LS 分发限制在一个管理域内。

隔离并不会降低信息敏感度。拓扑、容量和 TE 指标可能揭示关键节点、故障边界和商业能力。邻接应明确建立在受信 speaker 之间；只承担消费角色的 peer 不应获得发送 UPDATE 的能力。

Cisco IOS XR、IOS XE 与 Juniper 的官方文档展示了实例、域区分、策略、节流、表项和控制器邻居的真实操作面。这些是具体产品和版本的证据，不能被概括成所有实现的共同默认值。每次审计都要绑定软件版本、继承后的有效配置和现场状态。

Sources