Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 6213 L. Ginsberg
Category: Standards Track Cisco Systems
ISSN: 2070-1721 April 2011
Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 6213 L. Ginsberg
Category: Standards Track Cisco Systems
ISSN: 2070-1721 April 2011
IS-IS BFD-Enabled TLV
是否启用了BFD TLV
Abstract
摘要
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method.
本文档描述了IS-IS路由协议中使用的类型长度值（TLV），允许正确使用双向转发检测（BFD）协议。在某些情况下，IS-IS在不使用此TLV或其他方法的情况下不会对BFD检测到的转发平面故障做出适当反应。
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/rfc6213.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6213.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
1.1. Requirements Language ......................................2
2. The Problem .....................................................2
3. The Solution ....................................................3
3.1. State Definitions ..........................................3
3.2. Adjacency Establishment and Maintenance ....................4
3.3. Advertisement of Topology-Specific IS Neighbors ............4
4. Transition ......................................................4
5. Graceful Restart ................................................5
6. The BFD-Enabled TLV .............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgements ................................................6
10. Normative References ...........................................7
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. The Problem .....................................................2
3. The Solution ....................................................3
3.1. State Definitions ..........................................3
3.2. Adjacency Establishment and Maintenance ....................4
3.3. Advertisement of Topology-Specific IS Neighbors ............4
4. Transition ......................................................4
5. Graceful Restart ................................................5
6. The BFD-Enabled TLV .............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgements ................................................6
10. Normative References ...........................................7
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is a protocol that allows for detection of a forwarding plane failure between two routers. A router can use [RFC5880] to validate that a peer router's forwarding ability is functioning.
双向转发检测（BFD）协议[RFC5880]是一种允许检测两个路由器之间的转发平面故障的协议。路由器可以使用[RFC5880]来验证对等路由器的转发能力是否正常工作。
One specific application of BFD as described in [RFC5882] is to verify the forwarding ability of an IS-IS [RFC1195] router's adjacencies; however, the method described in [RFC5882] does not allow for certain failure scenarios. We will define a TLV that will allow for proper response to the detection of all forwarding failures where the use of BFD is employed with IS-IS.
[RFC5882]中描述的BFD的一个具体应用是验证is-is[RFC1195]路由器的邻接的转发能力；但是，[RFC5882]中描述的方法不允许出现某些故障情况。我们将定义一个TLV，该TLV将允许在is-is中使用BFD的情况下对所有转发故障的检测做出适当响应。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
We observe that, in order to allow for mixed use (i.e., some routers running BFD and some not), [RFC5882] does not require a BFD session be established prior to the establishment of an IS-IS adjacency. Thus, if a router A has neighbors B and C, and B does not support BFD, A would still form adjacencies with B and C, and it would only establish a BFD session with C.
我们观察到，为了允许混合使用（即，一些路由器运行BFD，而一些不运行BFD），[RFC5882]不需要在建立IS-IS邻接之前建立BFD会话。因此，如果路由器a有邻居B和C，而B不支持BFD，则a仍将与B和C形成邻接，并且它将仅与C建立BFD会话。
The problem with this solution is that it assumes that the transmission and receipt of IS-IS Hellos (IIHs) shares fate with forwarded data packets. This is not a fair assumption to make given that the primary use of BFD is to protect IPv4 (and IPv6) forwarding, and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its hellos.
此解决方案的问题在于，它假定is-is Hellos（IIHs）的传输和接收与转发的数据包共享命运。考虑到BFD的主要用途是保护IPv4（和IPv6）转发，并且is-is不利用IPv4或IPv6发送或接收其HELLO，这不是一个公平的假设。
Thus, if we consider our previous example, and if C is currently experiencing an IPv4 forwarding failure that allows for IIHs to be sent and received, when A first starts (or restarts), A will assume that C simply does not support BFD, will form an adjacency with C, and may incorrectly forward IPv4 traffic through C.
因此，如果我们考虑前面的示例，并且如果C当前经历了允许发送和接收IIHS的IPv4转发失败，则当第一次启动（或重新启动）时，A将假定C不支持BFD，将与C形成邻接，并且可能通过C错误转发IPv4流量。
A simple solution to this problem is for an IS-IS router to advertise that it has BFD enabled on a given interface. It can do this through the inclusion of a TLV in its IIHs as described in this document.
这个问题的一个简单解决方案是，is-is路由器在给定接口上公布它已启用BFD。如本文件所述，可通过在其IIH中包含TLV来实现这一点。
When sending an IIH on a BFD enabled interface, a router that supports this extension MUST include the BFD-enabled TLV in its IIH. The contents of the TLV MUST indicate what topologies/protocols [RFC5120] have been enabled for BFD by including the appropriate Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier (NLPID) pairs.
在启用BFD的接口上发送IIH时，支持此扩展的路由器必须在其IIH中包含启用BFD的TLV。TLV的内容必须通过包括适当的多拓扑标识符（MTID）/网络层协议标识符（NLPID）对来指示为BFD启用了哪些拓扑/协议[RFC5120]。
When sending an IIH on an interface on which BFD is NOT enabled, a router MUST NOT include the BFD-enabled TLV.
在未启用BFD的接口上发送IIH时，路由器不得包括启用BFD的TLV。
The following definitions apply to each IS-IS neighbor:
以下定义适用于每个IS-IS邻居：
For each locally supported MTID/NLPID pair, an "ISIS_TOPO_NLPID_BFD_REQUIRED" variable is assigned. If BFD is supported by both the local system and the neighbor of the MTID/ NLPID, this variable is set to "TRUE". Otherwise, the variable is set to "FALSE".
对于每个本地支持的MTID/NLPID对，分配一个“ISIS\u TOPO\u NLPID\u BFD\u REQUIRED”变量。如果本地系统和MTID/NLPID的邻居都支持BFD，则此变量设置为“TRUE”。否则，变量设置为“FALSE”。
For each locally supported MTID, an "ISIS_TOPO_BFD_REQUIRED" variable is set to the logical "OR" of all "ISIS_TOPO_NLPID_BFD_REQUIRED" variables associated with that MTID.
对于每个本地支持的MTID，一个“ISIS_TOPO_BFD_REQUIRED”变量设置为与该MTID关联的所有“ISIS_TOPO_NLPID_BFD_REQUIRED”变量的逻辑“或”。
An "ISIS_BFD_REQUIRED" variable is set to the logical "AND" of all "ISIS_TOPO_BFD_REQUIRED" variables.
“ISIS_BFD_REQUIRED”变量设置为所有“ISIS_TOPO_BFD_REQUIRED”变量的逻辑“和”。
For each locally supported MTID/NLPID pair, an "ISIS_TOPO_NLPID_STATE" variable is assigned. If "ISIS_TOPO_NLPID_BFD_REQUIRED" is "TRUE", this variable follows the BFD session state for that MTID/NLPID ("UP == TRUE"). Otherwise, the variable is set to "TRUE".
对于每个本地支持的MTID/NLPID对，分配一个“ISIS\u TOPO\u NLPID\u STATE”变量。如果“ISIS_TOPO_NLPID_BFD_REQUIRED”为“TRUE”，则此变量将跟随该MTID/NLPID的BFD会话状态（“UP==TRUE”）。否则，变量将设置为“TRUE”。
For each locally supported topology (MTID), an "ISIS_TOPO_USEABLE" variable is set to the logical "AND" of the set of "ISIS_TOPO_NLPID_STATE" variables associated with that MTID.
对于每个本地支持的拓扑（MTID），一个“ISIS\u TOPO\u USEABLE”变量被设置为与该MTID关联的“ISIS\u TOPO\u NLPID\u状态”变量集的逻辑“和”。
An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all "ISIS_TOPO_USEABLE" variables.
“ISIS\U邻居可用”变量设置为所有“ISIS\U拓扑可用”变量的逻辑“或”。
Whenever "ISIS_BFD_REQUIRED" is "TRUE", the following extensions to the rules for adjacency establishment and maintenance MUST apply:
当“ISIS_BFD_REQUIRED”为“TRUE”时，邻接建立和维护规则的以下扩展必须适用：
o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can transition from "INIT" to "UP" state.
o “ISIS_NEIGHBOR_USEABLE”必须为“TRUE”，相邻关系才能从“INIT”状态转换为“UP”状态。
o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE" becomes "FALSE", the IS-IS adjacency MUST transition to "DOWN".
o 当IS-IS邻接为“向上”且“ISIS\u邻居可用”变为“FALSE”时，IS-IS邻接必须转换为“向下”。
o On a Point-to-Point circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the Three-Way adjacency state MUST be set to "DOWN" in the Point-to-Point Three-Way Adjacency TLV [RFC5303] in all transmitted IIHs.
o 在点对点电路上，每当“ISIS_NEIGHBOR_USEABLE”为“FALSE”时，必须在所有传输IIH的点对点三向邻接TLV[RFC5303]中将三向邻接状态设置为“DOWN”。
o On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the IS Neighbors TLV advertising the Media Access Control (MAC) address of the neighbor MUST be omitted in all transmitted IIHs.
o 在LAN电路上，每当“ISIS_NEIGHBOR_USEABLE”为“FALSE”时，在所有传输的IIH中都必须省略宣传邻居媒体访问控制（MAC）地址的is NEIGHBOR TLV。
The advertisement of a topology-specific IS neighbor (as well as the use of the neighbor in the topology-specific decision process) is determined by the value of "ISIS_TOPO_USEABLE" for each topology. If "ISIS_TOPO_USEABLE" is "TRUE", then the topology-specific neighbor is advertised. If "ISIS_TOPO_USEABLE" is "FALSE", then the topology-specific neighbor is not advertised.
拓扑特定IS邻居的公布（以及在拓扑特定决策过程中使用邻居）由每个拓扑的“ISIS_TOPO_USEABLE”值确定。如果“ISIS\u TOPO\u USEABLE”为“TRUE”，则会公布特定于拓扑的邻居。如果“ISIS\u TOPO\u USEABLE”为“FALSE”，则不会公布拓扑特定的邻居。
To allow for a non-disruptive transition to the use of BFD, some amount of time should be allowed before bringing down an "UP" adjacency on a BFD enabled interface when the value of "ISIS_BFD_REQUIRED" becomes "TRUE" as a result of the introduction of
为了允许无中断地过渡到使用BFD，当“ISIS_BFD_REQUIRED”的值由于引入了
the BFD TLV or the modification (by adding a new supported MTID/ NLPID) of an existing BFD TLV in a neighbor's IIH. A simple way to do this is to not update the adjacency hold time when receiving such an IIH from a neighbor with whom we have an "UP" adjacency until "ISIS_NEIGHBOR_USEABLE" becomes "TRUE".
BFD TLV或邻居IIH中现有BFD TLV的修改（通过添加新的受支持的MTID/NLPID）。这样做的一个简单方法是，当从邻居那里接收到这样的IIH时，在“ISIS_neighbor_USEABLE”变为“TRUE”之前，不要更新邻接保持时间。
If the value of "ISIS_BFD_REQUIRED" becomes "FALSE" as a result of the removal the BFD TLV or the modification (by removing a supported MTID/NLPID) of an existing BFD TLV in a neighbor's IIH, then BFD session establishment is no longer required to maintain the adjacency or transition the adjacency to the "UP" state.
如果由于删除BFD TLV或修改（通过删除支持的MTID/NLPID）邻居IIH中的现有BFD TLV，“ISIS_BFD_REQUIRED”的值变为“FALSE”，则不再需要建立BFD会话来保持邻接或将邻接转换为“UP”状态。
If a BFD session is administratively shut down [RFC5880] and the BFD session state change impacts the value of "ISIS_NEIGHBOR_USEABLE", then IS-IS SHOULD allow time for the corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by not updating the adjacency hold time until "ISIS_BFD_REQUIRED" becomes "FALSE". Note that while this allows a non-disruptive transition, it still enforces consistency between the administrative state of the BFD session and the MTID/NLPID(s) advertised in the BFD TLV. This is necessary to provide consistent behavior regardless of whether the BFD AdminDown state is introduced before or after an IS-IS adjacency "UP" state has been achieved.
如果BFD会话被管理性关闭[RFC5880]，且BFD会话状态更改影响“ISIS_NEIGHBOR_USEABLE”的值，则is-is应允许相应的MTID/NLPID从邻居的BFD TLV中删除，方法是在“ISIS_BFD_REQUIRED”变为“FALSE”之前不更新邻接保持时间。请注意，虽然这允许无中断转换，但它仍然强制BFD会话的管理状态与BFD TLV中公布的MTID/NLPID之间保持一致。无论是在实现is-is邻接“向上”状态之前还是之后引入BFD AdminDown状态，这都是提供一致行为所必需的。
This section describes IS-IS implementation considerations when both IS-IS graceful restart [RFC5306] and BFD are co-deployed.
本节描述了IS-IS优雅重启[RFC5306]和BFD共同部署时的IS-IS实施注意事项。
In cases where BFD shares fate with the control plane, it can be expected that BFD session failure may occur in conjunction with the control-plane restart. In such cases, premature abort of IS-IS graceful restart as a result of BFD session failure is undesirable. Therefore, some mechanism to ignore the BFD session failure for a limited period of time would be beneficial. The issue of the interaction between graceful restart and BFD is described at length in RFC 5882. The implementation of this interaction is outside the scope of this document.
在BFD与控制平面命运相同的情况下，可以预期BFD会话失败可能与控制平面重启一起发生。在这种情况下，不希望由于BFD会话失败而过早中止IS-IS优雅重启。因此，一些在有限时间内忽略BFD会话失败的机制将是有益的。RFC 5882详细描述了优雅重启和BFD之间的交互问题。此交互的实现不在本文档的范围内。
The BFD-enabled TLV is formatted as shown below. The TLV SHALL only be included in an IIH and only when BFD is enabled for one or more supported MTID/protocols on the interface over which the IIH is being sent. The NLPIDs encoded in the TLV are defined in [ISO9577].
启用BFD的TLV的格式如下所示。TLV应仅包括在IIH中，且仅当在发送IIH的接口上为一个或多个受支持的MTID/协议启用BFD时。TLV中编码的NLPID在[ISO9577]中定义。
Type 148 Length # of octets in the value field (3 to 255) Value 3 octets specifying the MTID/NLPID for each topology/data protocol for which BFD support is enabled
在值字段（3到255）中键入148个八位字节的长度，值为3个八位字节，指定启用BFD支持的每个拓扑/数据协议的MTID/NLPID
No. of octets
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
: :
: :
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
No. of octets
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
: :
: :
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
The TLV defined within this document describes an addition to the IS-IS Hello protocol. Inappropriate use of this TLV could prevent an IS-IS adjacency from forming or lead to failure to detect bidirectional forwarding failures -- each of which is a form of denial of service. However, a party who can manipulate the contents of this TLV is already in a position to create such a denial of service by disrupting IS-IS routing in other ways.
本文档中定义的TLV描述了IS-IS Hello协议的一个补充。不适当地使用此TLV可能会阻止IS-IS邻接的形成或导致无法检测双向转发故障——每种故障都是拒绝服务的一种形式。但是，可以操纵此TLV内容的一方已经能够通过以其他方式中断is-is路由来创建此类拒绝服务。
Note that the introduction of this TLV has no impact on the use/ non-use of authentication either by IS-IS or by BFD.
请注意，该TLV的引入对IS-IS或BFD使用/不使用身份验证没有影响。
The following IS-IS TLV type is defined by this document.
本文件定义了以下IS-IS TLV类型。
Name Value IIH LSP SNP Purge
---------------------- ----- --- --- --- -----
BFD-Enabled TLV 148 y n n n
Name Value IIH LSP SNP Purge
---------------------- ----- --- --- --- -----
BFD-Enabled TLV 148 y n n n
The IS-IS TLV Codepoint registry has been updated accordingly.
IS-IS TLV代码点注册表已相应更新。
The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz, Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett, and David Ward for various input on this document.
作者希望感谢Jeffrey Haas、Matthew Jones、Dave Katz、Jonathan Moon、Stefano Previdi、Mike Shand、Michael Shiplett和David Ward对本文件的各种投入。
[ISO9577] International Organization for Standardization, "Protocol identification in the network layer(ISO/IEC 9577)", ISO/ IEC 9577:1999, Fourth Edition, December 1999.
[ISO9577]国际标准化组织，“网络层协议识别（ISO/IEC 9577）”，ISO/IEC 9577:1999，第四版，1999年12月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[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月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，2008年2月。
[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.
[RFC5303]Katz，D.，Saluja，R.，和D.Eastlake，“IS-IS点对点邻接的三方握手”，RFC 5303，2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306]Shand，M.和L.Ginsberg，“IS-IS的重启信号”，RFC 5306，2008年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882]Katz，D.和D.Ward，“双向转发检测（BFD）的一般应用”，RFC 5882，2010年6月。
Authors' Addresses
作者地址
Christian E. Hopps Cisco Systems 170 W. Tasman Dr. San Jose, California 95134 USA EMail: chopps@cisco.com
Christian E.Hopps Cisco Systems 170 W.Tasman博士加利福尼亚州圣何塞95134美国电子邮件：chopps@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, California 95035 USA EMail: ginsberg@cisco.com
莱斯金斯伯格思科系统公司，麦卡锡大道510号。加利福尼亚州米尔皮塔斯95035美国电子邮件：ginsberg@cisco.com