Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 7313 E. Chen
Updates: 2918 Cisco Systems
Category: Standards Track B. Venkatachalapathy
ISSN: 2070-1721 July 2014
Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 7313 E. Chen
Updates: 2918 Cisco Systems
Category: Standards Track B. Venkatachalapathy
ISSN: 2070-1721 July 2014
Enhanced Route Refresh Capability for BGP-4
增强的BGP-4路由刷新功能
Abstract
摘要
In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.
在本文档中，我们增强了现有的BGP路由刷新机制，以区分路由刷新的开始和结束。该增强功能可用于以无中断方式促进BGP路由信息库（RIB）不一致性的纠正。本文件更新了RFC 2918。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7313.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7313.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 2
3.1. Enhanced Route Refresh Capability . . . . . . . . . . . . 3
3.2. Subtypes for ROUTE-REFRESH Message . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 2
3.1. Enhanced Route Refresh Capability . . . . . . . . . . . . 3
3.2. Subtypes for ROUTE-REFRESH Message . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
It is sometimes necessary to perform routing consistency validations such as checking for possible missing route withdrawals between BGP speakers [RFC4271]. Currently, such validations typically involve offline, manual operations that can be tedious and time-consuming.
有时有必要执行路由一致性验证，例如检查BGP扬声器之间可能丢失的路由提取[RFC4271]。目前，此类验证通常涉及离线、手动操作，这可能会非常繁琐和耗时。
In this document, we enhance the existing BGP route refresh mechanisms [RFC2918] to provide for the demarcation of the beginning and the ending of a route refresh (which refers to the complete re-advertisement of the Adj-RIB-Out to a peer, subject to routing policies). The enhancement can be used to facilitate online, non-disruptive consistency validation of BGP routing updates.
在本文档中，我们增强了现有的BGP路由刷新机制[RFC2918]，以区分路由刷新的开始和结束（这是指根据路由策略向对等方完全重新公布Adj RIB Out）。该增强功能可用于促进BGP路由更新的在线、无中断一致性验证。
This document updates [RFC2918] by redefining a field in the ROUTE-REFRESH message that was previously designated as Reserved.
本文档通过重新定义ROUTE-REFRESH消息中先前指定为保留的字段来更新[RFC2918]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without any normative meaning.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”仅当出现在所有大写字母中时，才应按照[RFC2119]中所述进行解释。它们也可能以小写或混用的形式出现在英语单词中，没有任何规范意义。
The BGP protocol extensions introduced in this document include the definition of a new BGP capability, named "Enhanced Route Refresh Capability", and the specification of the message subtypes for the ROUTE-REFRESH message.
本文档中介绍的BGP协议扩展包括新BGP功能的定义，名为“增强路由刷新功能”，以及路由刷新消息的消息子类型规范。
The "Enhanced Route Refresh Capability" is a new BGP capability [RFC5492]. IANA has assigned a Capability Code of 70 for this capability. The Capability Length field of this capability is zero.
“增强路由刷新能力”是一种新的BGP能力[RFC5492]。IANA为此能力分配了70的能力代码。此功能的“功能长度”字段为零。
By advertising this capability to a peer, a BGP speaker conveys to the peer that the speaker supports the message subtypes for the ROUTE-REFRESH message and the related procedures described in this document.
通过向对等方宣传此功能，BGP演讲者向对等方传达演讲者支持ROUTE-REFRESH消息的消息子类型以及本文档中描述的相关过程。
The "Reserved" field of the ROUTE-REFRESH message specified in [RFC2918] is redefined as the "Message Subtype" with the following values:
[RFC2918]中指定的路由刷新消息的“保留”字段被重新定义为具有以下值的“消息子类型”：
0 - Normal route refresh request [RFC2918] with/without Outbound Route Filtering (ORF) [RFC5291] 1 - Demarcation of the beginning of a route refresh (BoRR) operation 2 - Demarcation of the ending of a route refresh (EoRR) operation 255 - Reserved
0-正常路由刷新请求[RFC2918]带/不带出站路由过滤（ORF）[RFC5291]1-路由刷新（BoRR）操作开始的标定2-路由刷新（EoRR）操作结束的标定255-保留
The remaining values of the message subtypes are reserved for future use; see Section 6 ("IANA Considerations"). The use of the new message subtypes is described in Section 4 ("Operation").
消息子类型的剩余值保留供将来使用；见第6节（“IANA注意事项”）。第4节（“操作”）介绍了新消息子类型的使用。
A BGP speaker that supports the message subtypes for the ROUTE-REFRESH message and the related procedures SHOULD advertise the "Enhanced Route Refresh Capability".
支持ROUTE-REFRESH消息和相关过程的消息子类型的BGP扬声器应宣传“增强的路由刷新功能”。
The following procedures are applicable only if a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer.
以下步骤仅适用于BGP扬声器从对等方接收到“增强路由刷新能力”的情况。
Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message.
在演讲者开始本地启动的路由刷新之前，或者响应来自对等方的“正常路由刷新请求”，演讲者必须发送BoRR消息。演讲者完成向对等方重新播发整个Adj RIB后，必须发送EoRR消息。
Conceptually, the "entire Adj-RIB-Out" for a peer in this section refers to all the route entries in the "Adj-RIB-Out" for the peer at the start of the route refresh operation. These route entries comprise both the reachability as well as unreachability information.
从概念上讲，本节中对等机的“整个Adj RIB Out”是指在路由刷新操作开始时对等机的“Adj RIB Out”中的所有路由条目。这些路由条目包括可达性和不可达性信息。
When a route entry in the "Adj-RIB-Out" changes, only the modified route entry needs to be advertised.
当“Adj RIB Out”中的路线条目发生更改时，只需公布修改后的路线条目。
In processing a ROUTE-REFRESH message from a peer, the BGP speaker MUST examine the "message subtype" field of the message and take the appropriate actions. The message processing rules for ROUTE-REFRESH message with subtype of 0 are described in [RFC2918] and [RFC5291]. A BGP speaker can receive a BoRR message from a peer at any time, either as a result of a peer responding to a ROUTE-REFRESH message, or as a result of a peer unilaterally initiating a route refresh. When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given Address Family Identifier and Subsequent Address Family Identifier, <AFI, SAFI> [RFC2918], from that peer as stale. As it receives routes from its peer's subsequent Adj-RIB-Out re-advertisement, these replace any corresponding stale routes. When a BGP speaker receives an EoRR message from a peer, it MUST immediately remove any routes from the peer that are still marked as stale for that <AFI, SAFI>. Such purged routes MAY be logged for future analysis. A BGP speaker MAY ignore any EoRR message received without a prior receipt of an associated BoRR message. Such messages MAY be logged for future analysis.
在处理来自对等方的路由刷新消息时，BGP演讲者必须检查消息的“消息子类型”字段并采取适当的操作。[RFC2918]和[RFC5291]中描述了子类型为0的路由刷新消息的消息处理规则。BGP演讲者可以随时从对等方接收BoRR消息，这可能是对等方响应路由刷新消息的结果，也可能是对等方单方面启动路由刷新的结果。当BGP扬声器从对等方接收到BoRR消息时，它必须将来自该对等方的具有给定地址族标识符和后续地址族标识符（<AFI，SAFI>[RFC2918]）的所有路由标记为过时。当它从其对等方的后续Adj RIB Out重新公布接收路由时，这些路由将替换任何相应的过时路由。当BGP扬声器从对等方接收到EoRR消息时，它必须立即从对等方删除仍然标记为过时的<AFI，SAFI>路由。这些清除的路由可能会被记录下来以供将来分析。BGP演讲者可以忽略在未事先收到相关BoRR消息的情况下收到的任何EoRR消息。这些消息可能会被记录下来以供将来分析。
An implementation MAY impose a locally configurable upper bound on how long it would retain any stale routes. Once the upper bound is reached, the implementation MAY remove any routes from the peer that are still marked as stale for that <AFI, SAFI> without waiting for an EoRR message.
一个实现可能会对保留任何过时路由的时间施加一个本地可配置的上限。一旦达到上限，实现就可以从对等方删除仍然标记为过时的<AFI，SAFI>路由，而无需等待EoRR消息。
The following procedures are specified in order to simplify the interaction with the BGP Graceful Restart [RFC4724]. In particular, these procedures ensure that End-of-RIB (EoR) defined in Graceful Restart and EoRR as defined in this specification are kept separate, thereby avoiding any premature cleanup of stale routes. For a BGP speaker that supports the BGP Graceful Restart, it MUST NOT send a BoRR for an <AFI, SAFI> to a neighbor before it sends the EoR for the <AFI, SAFI> to the neighbor. A BGP speaker that has received the Graceful Restart Capability from its neighbor MUST ignore any BoRRs for an <AFI, SAFI> from the neighbor before the speaker receives the EoR for the given <AFI, SAFI> from the neighbor. The BGP speaker SHOULD log an error of the condition for further analysis.
为了简化与BGP优雅重启[RFC4724]的交互，指定了以下步骤。特别是，这些程序确保本规范中定义的肋骨末端（EoR）与本规范中定义的EoRR分开，从而避免过早清理陈旧路线。对于支持BGP正常重启的BGP扬声器，在向邻居发送<AFI，SAFI>的EoR之前，不得向邻居发送<AFI，SAFI>的BoRR。从邻居处接收到优雅重启功能的BGP扬声器必须在从邻居处接收到给定<AFI，SAFI>的EoR之前忽略邻居处<AFI，SAFI>的任何BORR。BGP扬声器应记录条件错误，以便进一步分析。
This document defines a new NOTIFICATION error code:
本文档定义了一个新的通知错误代码：
Error Code Name
错误代码名
7 ROUTE-REFRESH Message Error
7路由刷新消息错误
The following error subcode is defined as well:
还定义了以下错误子代码：
Subcode Name
子代码名
1 Invalid Message Length
1无效的消息长度
The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer.
本节规定的错误处理仅适用于BGP扬声器从对等方接收到“增强路由刷新能力”的情况。
If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message.
如果接收到的消息子类型为1和2的ROUTE-REFRESH消息的长度（不包括固定大小的消息头）不是4，则BGP扬声器必须发送错误代码为“ROUTE-REFRESH message Error”且子代码为“无效消息长度”的通知消息。通知消息的数据字段必须包含完整的路由刷新消息。
When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 0, 1, or 2, it MUST ignore the received ROUTE-REFRESH message. It SHOULD log an error for further analysis.
当BGP扬声器接收到带有“消息子类型”字段而不是0、1或2的ROUTE-REFRESH消息时，它必须忽略接收到的ROUTE-REFRESH消息。它应该记录一个错误以便进一步分析。
This document defines the Enhanced Route Refresh Capability for BGP. In the "Capability Codes" registry, IANA has assigned it value 70, referencing this document.
本文档定义了BGP的增强路由刷新功能。在“能力代码”注册表中，IANA参考本文件将其赋值为70。
This document also defines two new subcodes for the Route Refresh message. They have been registered with the IANA in a new registry as follows:
本文档还为路由刷新消息定义了两个新的子代码。他们已在IANA的新登记处登记如下：
Under "Border Gateway Protocol (BGP) Parameters": Registry: "BGP Route Refresh Subcodes" Reference: [RFC7313] Registration Procedure(s): Values 0-127 Standards Action, values 128-254 First Come First Served
在“边界网关协议（BGP）参数”下：注册表：“BGP路由刷新子代码”参考：[RFC7313]注册过程：值0-127标准操作，值128-254先到先得
Value Code Reference
0 Route-Refresh [RFC2918], [RFC5291]
1 BoRR [RFC7313]
2 EoRR [RFC7313]
3-254 Unassigned
255 Reserved [RFC7313]
Value Code Reference
0 Route-Refresh [RFC2918], [RFC5291]
1 BoRR [RFC7313]
2 EoRR [RFC7313]
3-254 Unassigned
255 Reserved [RFC7313]
In addition, this document defines a NOTIFICATION error code and an error subcode related to the ROUTE-REFRESH message. IANA has changed the name of the "BGP Error Codes" to "BGP Error (Notification) Codes" and added this document as a reference. IANA has allocated a new error code from that registry with the name "ROUTE-REFRESH Message Error", referencing this document.
此外，本文档还定义了与ROUTE-REFRESH消息相关的通知错误代码和错误子代码。IANA已将“BGP错误代码”的名称更改为“BGP错误（通知）代码”，并添加本文件作为参考。IANA已从该注册表中分配了一个名为“ROUTE-REFRESH Message error”的新错误代码，引用了此文档。
IANA has created a new registry for the error subcodes as follows:
IANA已为错误子代码创建了一个新注册表，如下所示：
Under "Border Gateway Protocol (BGP) Parameters", under "BGP Error Subcodes": Registry: "BGP ROUTE-REFRESH Message Error subcodes" Reference: [RFC7313] Registration Procedure(s): Values 0-127 Standards Action, values 128-255 First Come First Served
在“边界网关协议（BGP）参数”下的“BGP错误子代码”下：注册表：“BGP路由-刷新消息错误子代码”参考：[RFC7313]注册过程：值0-127标准操作，值128-255先到先得
Value Name Reference 0 Reserved [RFC7313] 1 Invalid Message Length [RFC7313] 2-255 Unassigned
值名称引用0保留[RFC7313]1无效消息长度[RFC7313]2-255未分配
Security considerations are given in [RFC4272] , but they do not cover Route-Refresh and many other BGP extensions. This document does not significantly change the underlying security issues regarding Route-Refresh, although improved error handling may aid operational security.
[RFC4272]中给出了安全注意事项，但它们不包括路由刷新和许多其他BGP扩展。尽管改进的错误处理可能有助于操作安全性，但本文档并未显著改变路由刷新的基本安全问题。
The authors would like to thank 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, and Chris Hall for their review and comments. The authors would like to thank John Scudder for the review and contribution to this document.
作者要感谢Pedro Marques、Pradosh Mohapatra、Robert Raszuk、Pranav Mehta、Shyam Sethuram、Bruno Decarene、Martin Djernes、Jeff Haas、Ilya Varlashkin、Rob Shakir、Paul Jakma、Jie Dong、Qing Zeng、Albert Tian、Jakob Heitz和Chris Hall的评论和评论。作者要感谢John Scudder对本文件的审查和贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918]Chen，E.“BGP-4的路由刷新能力”，RFC 2918，2000年9月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 47242007年1月。
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008.
[RFC5291]Chen，E.和Y.Rekhter，“BGP-4的出站路由过滤能力”，RFC 5291，2008年8月。
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
[RFC5492]Scudder，J.和R.Chandra，“BGP-4的能力广告”，RFC 5492，2009年2月。
Authors' Addresses
作者地址
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号凯尔帕特尔思科系统公司，邮编95134
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Enke Chen Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
EMail: enkechen@cisco.com
EMail: enkechen@cisco.com
Balaji Venkatachalapathy
Balaji-Venkatachalapathy
EMail: balaji_pv@hotmail.com
EMail: balaji_pv@hotmail.com