摘要

  • RFC 5291 允许 BGP 接收方发送有类型的 Outbound Route Filter，由对端在本地出口策略之外再施加一层约束，从源头避免生成接收方最终会丢弃的更新。
  • ADD、REMOVE 与 REMOVE-ALL 改变的只是当前会话内、由 peer 提供的 ORF 状态；PERMIT 与 DENY 表达偏好。任何远端条目都不能删除发送方本地出口过滤，对端也可以选择不执行这项偏好。
  • IMMEDIATE 让变更与重通告立即生效；DEFER 只储存状态，等待后续提交。证明链必须贯穿源过滤表、线上编码、对端解码、本地出口、Adj-RIB-Out、UPDATE 与接收 RIB，并在每次会话重建后重新建立。

最容易误导人的证据来自客户自己的路由器。变更前收到近百万条 IPv4 路线，变更后只剩几百条；内存下降，策略命中计数增加。运营者于是写下：“上游已按要求只发送精简表。”

这句话没有被本地视图证明。普通 inbound prefix-list 也会产生同样结果，而上游仍可能为这个客户计算并发送完整表。客户只证明了自己拒绝了什么，没有证明对端少做了什么。ORF 的价值正是让这项偏好可以在生成更新之前生效，但其效果仍必须由两边共同观察。

请求与路线沿相反方向移动

没有 ORF 时，权限边界很清楚。发送方用本地 outbound policy 从自己的候选路线中构造面向某个 peer 的 Adj-RIB-Out；接收方再用 inbound policy 接受、改写或拒绝收到的路线。两边各管各的边界。

ORF 增加一条受限的反向信号。接收方把过滤条目发送给上游；上游可以把这些条目纳入专属于该接收方的出口过滤，从而根本不生成或不发送接收方不要的更新。路线仍从上游流向客户，偏好却从客户流向上游。

RFC 5291 明确规定这种状态是叠加关系。peer 提供的 ORF 与发送方本地配置的 outbound filter 一起作用。客户可以要求少收，却不能借 ORF 删除上游的安全过滤、商业出口规则或保密边界。REMOVE-ALL 的“全部”只指指定的 peer-supplied ORF 条目，不是所有出口政策。

标准还指出，发送出去的 ORF 表达本地偏好，对端可以选择遵守或不遵守。能力协商只是打开一个协议接口，不是获得远程执行权。依赖精简 feed 的客户仍要保留自己的入站保护，并验证上游实际发送的集合。

这是一种务实的数据主权。双方可以共同定义更节省资源的接口，但发送方仍决定愿意披露什么，接收方仍决定愿意接纳什么。协调提高效率，没有合并两张网络的政策域。

能力不是一个开关，而是带方向的类型交集

ORF 使用 BGP Capability code 3 在 OPEN 中协商。它不是简单的“支持 ORF”布尔值，而是逐项声明 AFI/SAFI、ORF 类型，以及本端愿意接收条目、想发送条目，还是两者都做。

只有双方声明的交集才构成有效关系。客户想为 IPv4 unicast 发送 Address Prefix ORF，而上游只愿意在另一 address family 或另一 ORF type 上接收，就没有这一项 IPv4 关系。IPv6 成功不能证明 IPv4；愿意发送也不能推导出愿意接收。

这个交集还会改变会话初始状态。对于存在非空交集的 AFI/SAFI，RFC 5291 建议未来发送方在收到首个合格 Route Refresh 之前不要先通告路线。该消息可以是不带 ORF 的普通 refresh，也可以是带条目并标记 IMMEDIATE 的请求。这让接收方有机会在第一波大表出现前装好偏好。

若交集为空，则执行普通 BGP 流程。因此，同一条 Established 会话可能在 IPv4 上等待首个请求，却在 IPv6 上正常开始发送，或反过来。单一绿色会话状态掩盖了方向、类型与 first-refresh 状态。

证据必须以 session epoch 为单位保存双方 OPEN。配置里的 send 或 receive 只是意图；真正的运行接口是实际协商出来的 family、type 与方向交集。

这不是把 prefix-list 文件复制到远端

RFC 5291 把条目抽象为 AFI/SAFI、ORF-Type、Action、Match 与类型专用值。ADD 增加条目，REMOVE 删除对应条目，REMOVE-ALL 清空指定 ORF。PERMIT 请求通过匹配更新，DENY 请求不通过匹配更新。

RFC 5292 定义常见的 Address Prefix ORF。条目包括 Sequence、Prefix、Length、Minlen 与 Maxlen，因而可以表达精确前缀、地址范围与 more-specific 长度边界。Sequence 决定匹配次序；没有明确次序，PERMIT 与 DENY 的组合就可能产生歧义。

本地 prefix-list 与远端收到的序列化条目是两个不同证据对象。生成器可能反转序号、写错最小长度、漏掉 deny、使用错误 AFI，或根本没有发送最新版本。给源文件做哈希，不能证明任何一项远端状态。

至少要保存四个身份：编辑器源表、编译后的本地 ORF、Route Refresh 里的线上字节、对端解码后保存的 received ORF。测试还要覆盖负空间：一个精确许可前缀、一个处于 Minlen/Maxlen 内的 more-specific、一个越过长度边界的路线、一条显式 deny，以及一条无论 ORF 如何都被上游本地出口挡住的路线。

若同一 peer 存在多个非空 ORF type，每条路线需要经过每一种。RFC 5291 的合并规则让 PERMIT 与 DENY 相遇时得出 DENY。只展示一种 prefix ORF 的面板可能会误报最终有效集合。

DEFER 把“写入状态”与“改变 feed”分开

ORF 条目装在 Route Refresh 中，却多出一个事务选择。IMMEDIATE 要求对端处理条目，并按新的 ORF 状态重新通告该 address family 的受影响路线。发送方必须重通告受影响路线，也可以重通告未受影响路线。

DEFER 只让对端储存修改，暂不重新通告。直到后续收到普通 Route Refresh，或收到标记 IMMEDIATE 的 ORF 消息，外部可见 feed 才提交变化。当 ORF 之外还有本地策略变更、需要完整重通告时，RFC 5291 要求先用 DEFER 发送新条目，再发送普通 refresh。

这个间隙很有用：多组条目可以一次性提交，不必让外部看见半成品。它也很危险：客户配置与对端 received ORF 都可能显示“新状态”，而旧 Adj-RIB-Out 仍在生效。

所以 DEFER 必须成为正式事务，而不是一个状态词。记录事务 ID、期望条目哈希、计划 commit、截止时间和 rollback。若延迟状态超出窗口，或 IMMEDIATE 提交的集合不是预期版本，应立即报警。

普通 Route Refresh 不会清除 ORF。它让对端在继续考虑已经收到的 ORF 后重通告。Enhanced Route Refresh 的开始/结束标记可以划定一次重传，却不能代替 ORF 变更记录。共享同一种消息外壳，不代表它们拥有同一种权限。

删除远端请求只能放宽到本地边界

删除 peer-supplied DENY 可能让更多路线通过 ORF；删除最后一条会移除这个 ORF。可是 feed 的最大范围始终受发送方本地 outbound policy 与其是否采纳偏好的限制。

这让 rollback 具有非对称性。客户可以恢复旧请求、清空 ORF 或停止协商；这些动作都不应该削弱上游自己的明确出口策略。如果上游把客户 ORF 当成唯一安全控制，它已经把偏好误当成授权。

客户也不应撤掉自己的 inbound protection。对端可以不执行 ORF、丢失状态、只支持不同类型，或在重建会话时没有形成预期交集。资源优化不能成为唯一准入防线。

无效状态可能导致整个旧 ORF 被删除

若消息携带未协商的 AFI/SAFI 或 type，相应条目会被忽略；REMOVE 找不到目标条目时也被忽略。这些分支一般保留原有状态。

但已选中 ORF 中出现无法识别的字段值时，RFC 5291 要求删除此前收到的整个指定 ORF。设计意图是避免保留只理解一半的过滤，运营结果却可能是 feed 扩张到本地出口边界。

这条失败路径必须在隔离 canary 中验证。发送一个安全的无效或不支持测试，事先预测它应当被整条消息忽略、仅忽略条目，还是删除旧 ORF。最终以 Adj-RIB-Out 与接收结果确认，不要只看 parser 日志。

安全审查还要覆盖资源滥用。被攻陷的接收方可以高频修改过滤，诱发计算和重通告；被攻陷的发送方可以宣称支持而实际忽略。双方都应限制 ORF 自动化的频率、条目数量与可作用范围。

会话结束就是自然有效期

ORF 的生命期是交换它的那一条 BGP 会话。会话结束，远端保存的 peer-supplied 状态随之结束。重置前的配置截图不能证明重建后的状态。

下一次会话要重新协商能力。对于存在交集的 family，首个合格 Route Refresh 再次决定何时开始 feed。竞争条件、漏发初始请求或 capability 变化，都可能在本地 prefix-list 文件完全没变时改变路线集合。

因此 session epoch 应是证据主键。把 OPEN 能力、首个 ORF/普通 refresh、实际接收条目、激活结果与首份 Adj-RIB-Out 快照绑定保存。若预期请求前就出现路线，或接收方认定已发送的请求从未到达，应立即告警。

会话结束也可以清除状态，但它是高影响重置，不是普通 rollback。优先发送明确的逆向 mutation，并验证 withdrawal 或 re-advertisement。只有能预测整个重启次序时才把 reset 纳入回滚。

两边的 canary 才能证明省下了工作

从低影响 peer 与一个 address family 开始。先用普通本地出口与入站过滤建立基线，测量发送候选、线上 UPDATE、接收输入与本地拒绝。

按预期方向协商 Address Prefix ORF。在第一波 feed 前发送包含狭窄 permit 与 deny 的 IMMEDIATE 请求。发送方确认解码条目和本地政策交集，比较 ORF 前候选与 Adj-RIB-Out；线上和接收方共同证明排除更新从未发送，而非最后被丢弃。

第二版使用 DEFER。证明远端 stored state 已改而 feed 未改，再用普通 Route Refresh 提交并核对精确差分。依次测试 REMOVE、不存在的 REMOVE、REMOVE-ALL 与 last-entry removal，并在不弱化本地出口政策的前提下恢复旧状态。

最后重置会话。证明旧 received ORF 已消失，并通过能力协商与 first-refresh 次序重建期望 feed。每个启用的 AFI/SAFI 都要单独重复。

验收结果不能只是“ORF enabled”。它应当是一份节省工作且保留主权的账本：哪些更新未再为此 peer 生成，哪些本地规则仍阻止披露，哪一个精确请求导致变化，哪一项接收观测确认了结果。

ORF 创造的是一种很窄的权利：请求邻网少说一些。它的安全来自拒绝相反推论。接收方不能要求更多披露，不能擦除发送方规则，也不能假设旧会话状态永久存在。正因为双方都不交出边界，协作才可以真正提高效率。