摘要

  • RFC 5195 要求 PE 在 VPN Join 后重新取得此前因无匹配导入 Route Target 而丢弃的信息，并明确使用 Route Refresh。策略提交只证明意图改变，不能证明远端路由已取回或 PIT 已重建。
  • L1VPN 自动发现传播的是成员与端口映射，供后续信令使用。它既不证明原始声明者有权发布该映射，也不证明资源已经预留、交叉连接已经完成或数据能够通过。

无需重启，不代表无需证明

RFC 5195 的 Join 和 Prune 可以在不拆除 BGP 连接的情况下完成。这是一项重要的运维优势：改变某个 L1VPN 的可见范围，不必把同一会话承载的其他控制信息一起打断。

但“无中断”很容易被误读成“自动完成”。两者完全不同。BGP 会话持续在线，只说明邻接关系没有断；它不能说明新策略需要的数据已经到达，也不能说明旧策略排除的数据已经从所有投影和缓存中消失。

在加入之前，没有任何本地 VPN 的导入 Route Target 与某条 L1VPN 信息匹配时，非路由反射器 PE 必须丢弃该信息。新的导入目标出现后，设备必须重新取得这些曾被丢弃的路由。RFC 5195 在这里要求使用 RFC 2918 的 Route Refresh 机制。

因此，一次 Join 至少包含四个独立事实：策略已安装、刷新已发出、所需路由已重新接收、PIT 已按新集合完成核对。只检查配置数据库，会把第一项借给后三项充当证明。

PIT 是投影，不是物理网络

端口信息表保存 L1VPN 中的 <CPI,PPI> 元组。CPI 是该 VPN 内唯一的客户端口标识，PPI 是提供商网络内唯一的提供商端口标识。表内同时存在本地信息与远端信息：本地部分来自直连 CE 端口或配置，远端部分来自其他 PE 的 BGP 自动发现。

把两类信息放进同一张表，是为了让后续信令能够解析地址。它没有让两类来源获得同等证据强度。远端元组仍然是一项收到并通过本地策略的声明。

RFC 5195 的表述很谨慎：这些信息对于“完成信令阶段”是必要的。必要条件不是完成状态。PIT 可以先于信令请求存在，也可以在准入失败、带宽不足、设备交叉连接失败或链路断裂时继续存在。

所以“已发现”不能升级为“已连接”。正确的状态链应继续记录信令请求与响应、资源准入、预留标识、设备交叉连接、连续性测试与实际流量。

导入规则只证明本地选择

RFC 5195 用 Route Target 扩展社区约束信息进入哪些 PIT。导出目标给本地信息打上范围标记，导入目标决定远端路由能否进入某个 VPN 的表。

匹配成功能证明本地规则选择了这条信息。它不能独立证明客户授权、物理挂接或发布者权限。错误的目标值可以沿完全正常的协议路径，把一个站点放进错误的 VPN。

这也是为什么 Join 验证不能只数路由。每个重新出现的元组还需要一条授权记录，说明哪个主体允许哪个 PE、CPI 与 PPI 属于该 L1VPN。否则刷新只是把曾经丢弃的声明重新运回，而没有回答声明是否应当存在。

身份认证没有替来源签字

RFC 5195 把安全边界说得很清楚：一个 PE 只有在确实挂接并且得到适当授权时，才能被发现为某个 L1VPN 的成员。如果任意节点都能注入广告，任何人都可能把站点加入任意 VPN。

对于直连 BGP 对等体，文档建议使用当时 RFC 2385 所述的认证方法；RFC 5925 后来定义了 TCP Authentication Option。这些保护能够回答相邻会话由谁控制。

信息经过中间 BGP 发言者时，问题变成传递信任。本地 PE 必须相信自己的邻居只接受其信任的邻居，链条逐级延伸。RFC 5195 明确承认，BGP 无法判定某一条收到的信息是否源自有权发布该信息的发言者。

因此，单一提供商网络只是“具有充分信任关系”的示例，不是一张自动授权书。内部身份、客户合同、端口挂接、策略配置依然可能彼此不一致。

Prune 的风险藏在旧投影里

Prune 删除导入目标后，设备可以丢弃不再匹配任何 PIT 的 L1VPN 路由。控制面会话不需要重置，这意味着宏观健康指标可能保持全绿。

真正要问的是生命周期是否闭合：路由是否撤除，PIT 是否删除元组，下游编排器和工单缓存是否收到无效通知，已经启动但尚未完成的信令是否被重新评估。只要某个消费者仍把旧元组当作权威，Prune 就只完成了配置层。

Join 与 Prune 因而需要同一种收据：变更前集合、策略版本、刷新或撤除事件、RIB 结果、PIT 结果、消费者确认以及明确的过期时间。

最大带宽不是此刻可用带宽

自动发现还可以携带远端接口的交换能力和最大 LSP 带宽，用于出口选择。这是一项合理的提示信息，但它不是实时测量，也不是资源预留。

如果控制器把“最大值”显示成“可用值”，再把选中显示成“已预留”，两个结论都没有新增证人。稳健的记录应保留广告来源与时间，随后分别记录测量、准入决定和预留结果。

分区系统要求声明观察范围

RFC 5195 允许按 VPN 分区路由反射器，也允许多个相互独立的 BGP 系统承载 VPN 信息。这使任何单个部件都不必保存全网所有 L1VPN 路由。

可扩展性的代价不是错误，而是观察边界。两个分区可以各自完整，却展示不同成员集合。要声称 PIT 完整，必须同时声明预期发布者、所处发现分区、策略版本、刷新状态和核对时间。一个局部视图不能仅凭界面居中就变成全局事实。

最小可携带收据

每个元组首先记录 VPN、CPI、PPI、本地或远端来源、相邻对等体、可观察的起源、Route Target 集合、导入决定以及明确的授权依据。接收时间与 PIT 安装时间不能合并。

随后另起一条执行链：信令、准入、预留、设备交叉连接、路径连续性与转发测试。Join、Prune、刷新和撤回必须包含下游核对。这不是 RFC 5195 规定的新线格式，而是把每个结论留在真正产生它的现实层。

Heng Lu 的原则在此不是哲学装饰。配置是意图，BGP 是声明传输，PIT 是投影，运行中的设备才是执行。最小初始规范应让各家自由实现自动化，同时禁止一个绿色摘要替所有底层事实发言。

来源

  1. RFC 5195 HTML
  2. RFC 5195 文本
  3. RFC 5195 信息页
  4. IETF Datatracker：RFC 5195
  5. RFC 5195 历史
  6. RFC 5195 参考文献
  7. RFC 5195 勘误
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu：现实层与符号权力
  19. Heng Lu：最小初始规范
  20. Heng Lu：运行代码优先