摘要

  • RFC 1482 的代理聚合示例采用“或”条件：三个组成前缀只要听见一个，骨干网就可以生成并传播更大的聚合前缀。这是压缩机制，不是全部子网可达的证明。
  • 提议中的聚合注册表分别记录前缀、Home AS、Announcing AS、目标邻居和联系人。注册意图、生成配置、运行路由和数据包结果属于不同证据层。

一条更短的路由把失败留给了后面

RFC 1482 讨论的不只是怎样把几条路由写成一条。它面对的是迁移次序不一致的问题：有的区域网络已经能直接宣告 CIDR 聚合前缀，有的还不能；而 NSFNET 又希望尽快减少骨干路由表的条目。

对已经具备能力的网络，骨干可以直接接收一个聚合前缀，并依据策略数据库中列出的 AS 判断这个宣告是否来自预期来源。对尚不具备能力的网络，骨干可以替它完成聚合。

文档给出的 GateD 示意规则把三个组成前缀放在一个“或”列表中。收到其中任何一个，骨干就可以像收到整个聚合前缀一样保存并向外传播它。规则语法当时仍待确定，逻辑后果却很明确：局部出现足以触发更大范围的声明。

于是，远端看到聚合前缀时，并不知道究竟哪个组成前缀触发了它。它也不知道其余组成前缀是否仍在、是否从未正确装载，或者是否已经撤回。聚合在控制平面存在，不等于覆盖的每一段地址都能把包送到终点。

RFC 1482 另外提醒了“空洞”问题。发往空洞地址的流量可能先跨越一个自治系统，随后才被丢弃。聚合把故障的显现位置向后移动：上游认为覆盖路由足以指路，真正缺失的更明细路径却要到更接近目的地的地方才暴露。

数据库记录的是允许听谁说，不是已经听见谁

NSFNET 原有的基于策略的路由数据库，会把一个网络号与若干预期宣告它的 AS 联系起来。RFC 1482 以网络 35 为例，列出主来源、次来源和更多后备来源。

这张表的作用是配置接收边界。它回答“从哪些 AS 来的宣告可以被期待”，而不是“某时某刻收到了哪条更新”。即使来源被列入，路由器仍可能没有收到更新；收到后也可能没有选中；选中后还可能没有装入转发表。

输出策略同样不是一份面向所有人的总表。announcetoAS 针对特定邻居，可以选择不受限、受限、显式加入、显式排除，甚至完全不向该邻居宣告。不同邻居看到不同投影，可能正是政策设计的结果。

区域和中层网络把这些政策提交给 Merit，再由工具把数据纳入 ANSnet 路由器配置。提交文本、数据库行、生成报告、配置文件、解析结果和运行状态之间，每一步都有版本与时间差。任何一步成功，都不能自动替后一步作证。

Home AS 不是所有观察点的直接来路

RFC 1482 提议的聚合注册表，把一个看似单一的前缀拆成多项责任：CIDR 前缀、Home AS、Announcing AS、Neighbor AS 列表和联系人。

Home AS 是最初把组成可达性聚合起来并向邻居宣告的提供者。Announcing AS 是继续把同一聚合前缀传给自己邻居的 AS。Neighbor AS 则限定这一行政策所面向的接收者。

示例中，AS 100 是聚合的“家”；同一前缀随后又以 AS 690、AS 200 和 AS 201 为宣告者分别出现，每行都有不同邻居。对位于 AS 200 下游的观察者来说，眼前的直接邻居可能是 AS 200。把它说成“从 Home AS 100 直接收到”，会抹掉实际的转宣关系；把 AS 200 改称 Home AS，则会抹掉最初聚合角色。

因此，注册表更像预定的传播责任图，而不是实时抓取的路由轨迹。更新可以通过电子邮件或在线工具送入，但文档没有定义经认证的发布链、运行更新的观察时间、撤回回执，或与路由器接收表、选路表、转发表的自动核对。其安全章节明确说没有讨论安全问题。

这个边界不是说注册表没有用。恰恰相反，它使跨网络协调成为可能。只是它回答的是“谁打算向谁宣告”，而不是“谁在何时实际宣告、谁接受了、包是否抵达”。

初期方案不会为下游恢复明细

RFC 1482 说，初期部署不会把聚合前缀重新拆成更具体的路由再向外发布。需要完整路由信息的邻居，应使用支持 CIDR 的协议；依靠默认路由的邻居仍可以把包发往聚合覆盖的目的地，却不会因此得到全部明细。

这意味着，一个观察点只看到较短前缀，不代表上游没有更具体知识；它可能只是没有把那些知识交给这个邻居。相反，上游内部存在明细，也不代表每个外部邻居都有权或能力收到。

RFC 1338 与后继的 RFC 1519 解释了 CIDR 在地址分配和路由聚合上的总体压力。RFC 1771 后来更系统地描述 BGP-4 的路由属性与 AS 路径。RFC 1786 又给出了更丰富的路由政策注册表达。这些后续文档帮助区分层次，却不能倒推 RFC 1482 的每项计划、示例和工具迁移都已按文实施。

从一封登记邮件到路由器，中间并非同一件东西

RFC 1482 希望聚合信息能被 NSFNET 之外的参与者电子检索。登记和更新可以通过邮件或在线注册工具完成；数据库工具、报表、客户端解析器和配置生成程序都需要随之改变。文档还指出 rcp_routed 与 GateD 的概念差异。

这条链上的每个产物都可能不同步。注册行可能已更新，生成文件仍是旧版；文件可能生成成功，却未装入运行进程；进程可能收到路由，但因选路或输出过滤没有传播；控制平面可能有覆盖路由，转发表却把某个空洞流量送向丢弃点。

所以，调查不能从数据库跳到用户结果。它必须逐层保留版本、时间和主体。

33% 是规划估算，不是上线成绩

文档计算了一个可能的减少量：在 12,348 条宣告中减去 4,135 条，约为 33%。它同时把这个数字称为使用保守算法得到的乐观估算，并承认实际节省可能不同。

这不是生产路由器上线前后的实测对照，也不能独自回答路由表未来增长或地址耗尽问题。RFC Editor 条目 现将 RFC 1482 标为 Historic。正文当时说实施正在进行，同时把规划、讨论、调试、稳定性、决策算法与空洞处理列为尚需工作的问题。“正在进行”是一种项目状态，不是某台设备已经装载某版配置的证明。

可扩展性越依赖摘要，审计越依赖出处

聚合的成就，是让许多潜在目的地用一条较短声明进入远端视野。它的代价，是那条声明不再携带全部组成历史。

因此真正需要保存的是一条证据链：组成前缀与聚合边界；Home AS 的初始意图；每个转宣 AS 的邻居投影；注册表版本；生成和安装的配置；实际收到、选中和输出的路由；转发表下一跳；最后的数据包与服务结果。

如果只保存最终聚合，未来仍能知道“这条路由曾经存在”，却可能再也无法回答：是谁让它出现，哪一个组成前缀触发了代理规则，哪些邻居本来应该看见，以及哪个被摘要遮住的空洞吞掉了流量。

来源