RFC7313：Enhanced Route Refresh Capability for BGP-4，July 2014
梗概
在本文档中，我们增强了现有的 BGP 路由刷新机制，以提供路由刷新开始和结束的划分。该增强功能可用于促进以非中断方式更正 BGP 路由信息库 (Routing Information Base，RIB) 的不一致性。本文档更新了 RFC 2918。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7313。
版权声明
版权所有 (c) 2014 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
1、 简介
有时需要执行路由一致性验证，例如检查 BGP 发言者之间可能丢失的路由撤销 [RFC4271]。目前，此类验证通常涉及离线、手动操作，这可能是乏味且耗时的。
在本文档中，我们增强了现有的 BGP 路由刷新机制 [RFC2918] 以提供路由刷新的开始和结束的划分（指将 Adj-RIB-Out 完全重新通告给对等方，受路由策略的约束）。该增强功能可用于促进 BGP 路由更新的在线、无中断一致性验证。
本文档通过重新定义先前指定为保留的 ROUTE-REFRESH 消息中的字段来更新 [RFC2918]。
2、 需求语言
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是仅当它们以全部大写形式出现时，才按照 [RFC2119] 中的描述进行解释。它们也可能以小写或混合大小写的形式出现为英语单词，没有任何规范意义。
3、 协议扩展
本文档中介绍的 BGP 协议扩展包括新 BGP 能力的定义，称为“增强的路由刷新能力”，以及 ROUTE-REFRESH 消息的消息子类型规范。
3.1、 增强的路由刷新能力
“增强的路由刷新能力”是一种新的 BGP 能力 [RFC5492]。IANA 已为此功能分配了 70 的功能代码。该能力的能力长度字段为零。
通过向对等方通告这种能力，BGP 发言者向对等方传达该发言者支持 ROUTE-REFRESH 消息的消息子类型以及本文档中描述的相关过程。
3.2、 ROUTE-REFRESH 消息的子类型
[RFC2918] 中指定的 ROUTE-REFRESH 消息的“保留”字段被重新定义为具有以下值的“消息子类型”：
0 - 正常路由刷新请求 [RFC2918] 带/不带出站路由过滤 (Outbound Route Filtering，ORF) [RFC5291]1 - 路由刷新操作开始的划分(beginning of a route refresh，BoRR)2 - 路由刷新操作结束的划分(ending of a route refresh，EoRR)255 - 保留
消息子类型的剩余值保留供将来使用；请参阅第 6 节（“IANA 注意事项”）。第 4 节（“操作”）中描述了新消息子类型的使用。
4、 操作
支持 ROUTE-REFRESH 消息和相关程序的消息子类型的 BGP 发言者应该通告“增强的路由刷新能力”。
仅当 BGP 发言者从对等方接收到“增强的路由刷新能力”时，以下过程才适用。
在发言者开始本地发起的路由刷新之前，或者响应来自对等方的“正常路由刷新请求”，发言者必须发送 BoRR 消息。在说话者完成整个 Adj-RIB-Out 向对等方的重新通告后，它必须发送 EoRR 消息。
从概念上讲，本节中对等体的“整个Adj-RIB-Out”是指在路由刷新操作开始时对等体的“Adj-RIB-Out”中的所有路由条目。这些路由条目包括可达性和不可达性信息。
当“Adj-RIB-Out”中的路由条目发生变化时，只需要发布修改后的路由条目即可。
在处理来自对等点的 ROUTE-REFRESH 消息时，BGP 发言者必须检查消息的“消息子类型”字段并采取适当的措施。子类型为 0 的 ROUTE-REFRESH 消息的消息处理规则在 [RFC2918] 和 [RFC5291] 中有描述。BGP发言者可以在任何时候从对等体接收到BoRR消息，或者作为对等体响应ROUTE-REFRESH消息的结果，或者作为对等体单方面发起路由刷新的结果。当 BGP 发言者从对等体接收到 BoRR 消息时，它必须使用给定的地址族标识符和后续地址族标识符，<AFI，SAFI> [RFC2918]，从该对等体标记所有路由为陈旧的。当它从其对等方的后续 Adj-RIB-Out 重新通告接收路由时，这些路由将替换任何相应的陈旧路由。当 BGP 发言者从对等方接收到 EoRR 消息时，它必须立即从对等方删除仍然标记为该 <AFI，SAFI> 过时的任何路由。可以记录此类清除路线以供将来分析。BGP 发言者可以忽略在没有事先收到相关 BoRR 消息的情况下收到的任何 EoRR 消息。可能会记录此类消息以供将来分析。
一个实现可以对它保留任何陈旧路由的时间施加一个本地可配置的上限。一旦达到上限，实现可以从对等体中删除仍然标记为该 <AFI, SAFI> 陈旧的任何路由，而无需等待 EoRR 消息。
为了简化与 BGP Graceful Restart [RFC4724] 的交互，指定了以下过程。特别是，这些程序确保在 Graceful Restart 中定义的 End-of-RIB (EoR) 和本规范中定义的 EoRR 保持分离，从而避免过早清除过时的路由。对于支持 BGP Graceful Restart 的 BGP 发言者，它在将 <AFI, SAFI> 的 EoR 发送给邻居之前不得向邻居发送 <AFI, SAFI> 的 BoRR。从邻居那里接收到 Graceful Restart Capability 的 BGP 发言者必须在发言者从邻居接收到给定 <AFI, SAFI> 的 EoR 之前忽略来自邻居的 <AFI, SAFI> 的任何 BoRR。BGP 发言者应该记录条件错误以供进一步分析。
5、 错误处理
本文档定义了一个新的 NOTIFICATION 错误代码：
还定义了以下错误子代码：
本节规定的错误处理仅适用于 BGP 发言者从对等方接收到“增强的路由刷新能力”。
如果收到的消息子类型为 1 和 2 的 ROUTE-REFRESH 消息的长度（不包括固定大小的消息头）不为 4，则 BGP 发言者必须发送错误代码为“ROUTE-REFRESH 消息错误”的 NOTIFICATION 消息以及“无效消息长度”的子码。NOTIFICATION 消息的数据字段必须包含完整的 ROUTE-REFRESH 消息。
当 BGP 发言者接收到“消息子类型”字段不是 0、1 或 2 的 ROUTE-REFRESH 消息时，它必须忽略接收到的 ROUTE-REFRESH 消息。它应该记录一个错误以供进一步分析。
6、 IANA 考虑事项
本文档定义了 BGP 的增强路由刷新功能。在“能力代码”注册表中，IANA 已将其指定为 70，参考此文档。
本文档还为 Route Refresh 消息定义了两个新的子代码。他们已在新的注册机构中向 IANA 注册，如下所示：
在“边界网关协议 (Border Gateway Protocol，BGP) 参数”下：
注册表：“BGP 路由刷新子代码”
参考：[RFC7313]
注册程序：值 0-127 标准分配，值 128-254 先到先得
另外，本文档定义了一个NOTIFICATION错误代码和一个与ROUTE-REFRESH消息相关的错误子代码。IANA 已将“BGP 错误代码”的名称更改为“BGP 错误（通知）代码”，并添加了此文档作为参考。IANA 已从该注册表中分配了一个名为“ROUTE-REFRESH 消息错误”的新错误代码，并引用了此文档。
IANA 为错误子代码创建了一个新的注册表，如下所示：
在“边界网关协议 (BGP) 参数”下，在“BGP 错误子代码”下：
注册表：“BGP ROUTE-REFRESH 消息错误子代码”
参考：[RFC7313]
注册程序：值 0-127 标准分配，值 128-255 先到先得
7、 安全考虑
安全注意事项在 [RFC4272] 中给出，但它们不包括 Route-Refresh 和许多其他 BGP 扩展。本文档不会显着改变有关 Route-Refresh 的基本安全问题，尽管改进的错误处理可能有助于操作安全性。
8、 致谢
作者要感谢 Pedro Marques, Pradosh Mohapatra, Robert Raszuk, Pranav Mehta, Shyam Sethuram, Bruno Decraene, Martin Djernaes, Jeff Haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, Jie Dong, Qing Zeng, Albert Tian, Jakob Heitz , 和 Chris Hall 的评论和评论。作者要感谢 John Scudder 对本文档的审阅和贡献。
9、 规范性参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
