Internet Engineering Task Force (IETF) M. Bhatia, Ed.
Request for Comments: 7130 Alcatel-Lucent
Category: Standards Track M. Chen, Ed.
ISSN: 2070-1721 Huawei Technologies
S. Boutros, Ed.
M. Binderberger, Ed.
Cisco Systems
J. Haas, Ed.
Juniper Networks
February 2014
Internet Engineering Task Force (IETF) M. Bhatia, Ed.
Request for Comments: 7130 Alcatel-Lucent
Category: Standards Track M. Chen, Ed.
ISSN: 2070-1721 Huawei Technologies
S. Boutros, Ed.
M. Binderberger, Ed.
Cisco Systems
J. Haas, Ed.
Juniper Networks
February 2014
Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
链路聚合组（LAG）接口上的双向转发检测（BFD）
Abstract
摘要
This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.
本文档定义了在链路聚合组（LAG）接口上运行双向转发检测（BFD）的机制。它通过在每个LAG成员链接上运行独立的异步模式BFD会话来实现。
This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.
该机制允许在结合或不结合链路聚合控制协议（LACP）的情况下验证成员链路的连续性。它比LACP提供的检测时间更短。连续性检查还可以覆盖第3层（L3）双向转发的元素。
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/rfc7130.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7130.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BFD on LAG Member Links . . . . . . . . . . . . . . . . . . . 3
2.1. Micro-BFD Session Address Family . . . . . . . . . . . . 4
2.2. Micro-BFD Session Negotiation . . . . . . . . . . . . . . 4
2.3. Micro-BFD Session Ethernet Details . . . . . . . . . . . 5
3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6
4. BFD on LAG Member Links and L3 Applications . . . . . . . . . 6
5. Detecting a Member Link Failure . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Considerations When Using BFD on Member Links . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BFD on LAG Member Links . . . . . . . . . . . . . . . . . . . 3
2.1. Micro-BFD Session Address Family . . . . . . . . . . . . 4
2.2. Micro-BFD Session Negotiation . . . . . . . . . . . . . . 4
2.3. Micro-BFD Session Ethernet Details . . . . . . . . . . . 5
3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6
4. BFD on LAG Member Links and L3 Applications . . . . . . . . . 6
5. Detecting a Member Link Failure . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Considerations When Using BFD on Member Links . . . 10
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] provides a mechanism to detect faults in the bidirectional path between two forwarding engines, including interfaces, data links, and to the extent possible the forwarding engines themselves, with potentially very low latency. The BFD protocol also provides a fast mechanism for detecting communication failures on any data links and the protocol can run over any media and at any protocol layer.
双向转发检测（BFD）协议[RFC5880]提供了一种机制，用于检测两个转发引擎之间的双向路径中的故障，包括接口、数据链路，并尽可能检测转发引擎本身，潜在的延迟非常低。BFD协议还提供了一种快速机制，用于检测任何数据链路上的通信故障，该协议可以在任何媒体和任何协议层上运行。
LAG, as defined in [IEEE802.1AX], provides mechanisms to combine multiple physical links into a single logical link. This logical link provides higher bandwidth and better resiliency, because if one
如[IEEE802.1AX]中所定义，LAG提供了将多个物理链路组合成单个逻辑链路的机制。这种逻辑链路提供了更高的带宽和更好的弹性，因为如果
of the physical member links fails, the aggregate logical link can continue to forward traffic over the remaining operational physical member links.
如果一个物理成员链路出现故障，聚合逻辑链路可以继续转发剩余操作物理成员链路上的流量。
Currently, the Link Aggregation Control Protocol (LACP) is used to detect failures on a per-physical-member link. However, the use of BFD for failure detection would (1) provide a faster detection, (2) provide detection in the absence of LACP, and (3) would be able to verify the ability for each member link to be able to forward L3 packets.
目前，链路聚合控制协议（LACP）用于检测每个物理成员链路上的故障。然而，使用BFD进行故障检测将（1）提供更快的检测，（2）在没有LACP的情况下提供检测，（3）能够验证每个成员链路能够转发L3数据包的能力。
Running a single BFD session over the aggregation without internal knowledge of the member links would make it impossible for BFD to guarantee detection of the physical member link failures.
在聚合上运行单个BFD会话而不了解成员链接的内部信息将使BFD无法保证检测物理成员链接故障。
The goal is to verify link Continuity for every member link. This corresponds to [RFC5882], Section 7.3.
目标是验证每个成员链接的链接连续性。这与[RFC5882]第7.3节相对应。
The approach taken in this document is to run an Asynchronous mode BFD session over each LAG member link and make BFD control whether the LAG member link should be part of the L2 load-balancing table of the LAG interface in the presence or the absence of LACP.
本文采用的方法是在每个LAG成员链路上运行异步模式BFD会话，并使BFD控制在存在或不存在LACP的情况下，LAG成员链路是否应成为LAG接口的L2负载平衡表的一部分。
This document describes how to establish an Asynchronous mode BFD session per physical LAG member link of the LAG interface.
本文档描述了如何为LAG接口的每个物理LAG成员链接建立异步模式BFD会话。
While there are native Ethernet mechanisms to detect failures (802.1ax, .3ah) that could be used for LAG, the solution defined in this document enables operators who have already deployed BFD over different technologies (e.g., IP, MPLS) to use a common failure detection mechanism.
虽然存在本机以太网机制来检测可用于LAG的故障（802.1ax、.3ah），但本文档中定义的解决方案使已经通过不同技术（如IP、MPLS）部署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]中所述进行解释。
The mechanism defined for a fast detection of LAG member link failure is to run Asynchronous mode BFD sessions on every LAG member link. We call these per-LAG-member-link BFD sessions "micro-BFD sessions" in the remainder of this document.
为快速检测滞后成员链路故障而定义的机制是在每个滞后成员链路上运行异步模式BFD会话。在本文档的其余部分中，我们将这些每个LAG成员链接BFD会话称为“微型BFD会话”。
Member link micro-BFD sessions, when using IP/UDP encapsulation, can use IPv4 or IPv6 addresses. Two micro-BFD sessions MAY exist per member link: one IPv4 another IPv6. When an address family is used on one member link, then it MUST be used on all member links of the particular LAG.
使用IP/UDP封装时，成员链接微型BFD会话可以使用IPv4或IPv6地址。每个成员链路可能存在两个微型BFD会话：一个IPv4会话，另一个IPv6会话。当一个地址族用于一个成员链接时，它必须用于特定延迟的所有成员链接。
A single micro-BFD session for every enabled address family runs on each member link of the LAG. The micro-BFD session's negotiation MUST follow the same procedures defined in [RFC5880] and [RFC5881].
每个启用的地址系列的单个micro BFD会话在LAG的每个成员链接上运行。micro BFD会话的协商必须遵循[RFC5880]和[RFC5881]中定义的相同程序。
Only Asynchronous mode BFD is considered in this document; the use of the BFD echo function is outside the scope of this document. At least one system MUST take the Active role (possibly both). The micro-BFD sessions on the member links are independent BFD sessions. They use their own unique local discriminator values, maintain their own set of state variables, and have their own independent state machines. Timer values MAY be different, even among the micro-BFD sessions belonging to the same aggregation, although it is expected that micro-BFD sessions belonging to the same aggregation will use the same timer values.
本文件仅考虑异步模式BFD；BFD回波功能的使用不在本文档的范围内。必须至少有一个系统担任主动角色（可能同时担任这两个角色）。成员链接上的微型BFD会话是独立的BFD会话。它们使用自己独特的局部鉴别器值，维护自己的状态变量集，并拥有自己独立的状态机。计时器值可能不同，即使在属于同一聚合的micro BFD会话之间也是如此，尽管预期属于同一聚合的micro BFD会话将使用相同的计时器值。
The demultiplexing of a received BFD packet is solely based on the Your Discriminator field, if this field is nonzero. For the initial Down BFD packets of a BFD session, this value MAY be zero. In this case, demultiplexing MUST be based on some combination of other fields that MUST include the interface information of the member link and the destination UDP port of the received BFD packet.
接收到的BFD数据包的解复用仅基于您的鉴别器字段（如果该字段非零）。对于BFD会话的初始下行BFD数据包，该值可能为零。在这种情况下，解复用必须基于其他字段的某些组合，这些字段必须包括成员链路的接口信息和接收到的BFD数据包的目标UDP端口。
The procedure for the reception of BFD control packets in Section 6.8.6 of [RFC5880] is amended as follows for per-LAG-member-link micro-BFD sessions:
[RFC5880]第6.8.6节中BFD控制数据包的接收程序针对每个滞后成员链路微型BFD会话修改如下：
If the Your Discriminator field is nonzero and a micro-BFD over a LAG session is found, the interface on which the micro-BFD control packet arrived MUST correspond to the interface associated with that session.
如果Your Discriminator字段为非零，并且在滞后会话上找到micro BFD，则micro BFD控制数据包到达的接口必须与该会话相关联的接口相对应。
This document defines the BFD control packets for each micro BFD session to be IP/UDP encapsulated as defined in [RFC5881], but with a new UDP destination port 6784.
本文档定义了每个微型BFD会话的BFD控制数据包，这些数据包将按照[RFC5881]中的定义进行IP/UDP封装，但具有新的UDP目标端口6784。
The new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. An example is (mis-)configuring a LAG with micro-BFD sessions on one side but using a [RFC5881] BFD session for the LAG (treated as a single interface) on the opposite side.
新的UDP端口消除了BFD over LAG数据包在单跳IP上的模糊性。一个例子是（错误地）在一侧使用微型BFD会话配置LAG，但在另一侧使用[RFC5881]BFD会话配置LAG（视为单个接口）。
The procedures in this document MUST be used for BFD messages addressed to port 6784 and MUST NOT be used for others ports assigned in RFCs describing other BFD modes.
本文档中的程序必须用于发送至端口6784的BFD消息，不得用于在RFC中分配的描述其他BFD模式的其他端口。
Control packets use a destination IP address that is configured on the peer system and can be reached via the LAG interface.
控制数据包使用在对等系统上配置的目标IP地址，并且可以通过LAG接口访问该地址。
Implementations may range from explicitly configuring IP addresses for the BFD sessions to out-of-band methods for learning the destination IP address. The details are outside the scope of this document.
实现的范围可能从为BFD会话显式配置IP地址到学习目标IP地址的带外方法。这些细节不在本文件的范围之内。
On Ethernet-based LAG member links, the destination Media Access Control (MAC) is the dedicated multicast MAC address 01-00-5E-90-00-01 to be the immediate next hop. This dedicated MAC address MUST be used for the initial BFD packets of a micro-BFD session when in the Down/AdminDown and Init states. When a micro-BFD session is changing into the Up state, the first bfd.DetectMult packets in the Up state MUST be sent with the dedicated MAC. For BFD packets in the Up state following the first bfd.DetectMult packets, the source MAC address from the received BFD packets for the session MAY be used instead of the dedicated MAC.
在基于以太网的LAG成员链路上，目标媒体访问控制（MAC）是作为下一跳的专用多播MAC地址01-00-5E-90-00-01。当处于Down/AdminDown和Init状态时，此专用MAC地址必须用于micro BFD会话的初始BFD数据包。当micro BFD会话变为Up状态时，处于Up状态的第一个BFD.DetectMult数据包必须与专用MAC一起发送。对于在第一个BFD.DetectMult包之后处于Up状态的BFD包，可以使用来自用于会话的接收的BFD包的源MAC地址，而不是专用MAC。
All implementations MUST be able to send and receive BFD packets in Up state using the dedicated MAC address. Implementations supporting both, sending BFD Up packets with the dedicated and the received MAC, need to offer means to control the behaviour.
所有实现必须能够使用专用MAC地址在Up状态下发送和接收BFD数据包。支持这两者的实现，使用专用MAC和接收MAC发送BFD-Up数据包，需要提供控制行为的方法。
On Ethernet-based LAG member links, the source MAC SHOULD be the MAC address of the member link transmitting the packet.
在基于以太网的LAG成员链路上，源MAC应该是传输数据包的成员链路的MAC地址。
This mechanism helps to reduce the use of additional MAC addresses, which reduces the required resources on the Ethernet hardware on the receiving member link.
此机制有助于减少额外MAC地址的使用，从而减少接收成员链路上以太网硬件上所需的资源。
Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the micro-BFD packets may either be untagged or be sent with a vlan tag of Zero (802.1p priority tagged). Implementations compliant with this standard MUST be able to receive both untagged and 802.1p priority tagged micro-BFD packets.
Micro BFD数据包应始终未标记地发送。然而，当延迟在IEEE 802.1q或IEEE 802.1q的上下文中操作时，微BFD分组可以是未标记的，或者使用零的vlan标记（802.1p优先级标记）发送。符合本标准的实现必须能够接收未标记和802.1p优先级标记的micro BFD数据包。
The micro-BFD sessions for a particular LAG member link MUST be requested when a member link state is either Distributing or Standby. The sessions MUST be deleted when the member link is in neither Distributing nor Standby state anymore.
当成员链接状态为分发或备用时，必须请求特定LAG成员链接的micro BFD会话。当成员链接不再处于分发或备用状态时，必须删除会话。
BFD is used to control if the load-balancing algorithm is able to select a particular LAG member link. In other words, even when Link Aggregation Control Protocol (LACP) is used and considers the member link to be ready to forward traffic, the member link MUST NOT be used by the load balancer until all the micro-BFD sessions of the particular member link are in Up state.
BFD用于控制负载平衡算法是否能够选择特定的滞后成员链接。换句话说，即使在使用链路聚合控制协议（LACP）并认为成员链路已准备好转发流量时，负载平衡器也不得使用成员链路，直到特定成员链路的所有micro BFD会话处于启动状态。
In case an implementation has separate load-balancing tables for IPv4 and IPv6 and if both an IPv4 and IPv6 micro-BFD session exist for a member link, then an implementation MAY enable the member link in the load-balancing algorithm based on the BFD session with a matching address family alone.
如果一个实现对IPv4和IPv6有单独的负载平衡表，并且如果成员链路同时存在IPv4和IPv6微型BFD会话，则一个实现可以在负载平衡算法中仅基于BFD会话和匹配的地址族启用该成员链路。
An exception is the BFD packet itself. Implementations MAY receive and transmit BFD packets via the Aggregator's MAC service interface, independent of the session state.
一个例外是BFD数据包本身。实现可以通过聚合器的MAC服务接口接收和发送BFD分组，与会话状态无关。
The mechanism described in this document is likely to be used by modules managing Interfaces or LAGs and, thus, managing the member links of a LAG. Typical L3 protocols like OSPF do not have an insight into the LAG and treat it as one bigger interface. The signaling from micro sessions to L3 protocols is effectively done by the impact of micro-BFD sessions on the load-balancing table and the Interface/LAG managing module's potential decision to shut down the LAG. An active method to test the impact of micro-BFD sessions is for L3 protocols to request a single BFD session per LAG.
本文档中描述的机制可能由管理接口或LAG的模块使用，从而管理LAG的成员链接。像OSPF这样的典型L3协议不能洞察延迟，并将其视为一个更大的接口。通过micro BFD会话对负载平衡表的影响以及接口/滞后管理模块关闭滞后的潜在决策，可以有效地完成从micro会话到L3协议的信令。测试微BFD会话影响的一种主动方法是，L3协议每延迟一次请求一个BFD会话。
When a micro-BFD session goes down, this member link MUST be taken out of the LAG load-balancing table(s).
当micro BFD会话停止时，必须从滞后负载平衡表中删除此成员链接。
In case an implementation has separate load-balancing tables for IPv4 and IPv6, then if both an IPv4 and IPv6 micro-BFD session exist for a member link, an implementation MAY remove the member link only from the load-balancing table that matches the address family of the failing BFD session. For example, the IPv4 micro-BFD session fails but the IPv6 micro-BFD session stays Up, then the member link MAY be removed from only the IPv4 load balance table; the link MAY remain in
如果一个实现有单独的IPv4和IPv6负载平衡表，那么如果成员链路的IPv4和IPv6微型BFD会话都存在，则一个实现只能从与失败BFD会话的地址族匹配的负载平衡表中删除该成员链路。例如，IPv4 micro BFD会话失败，但IPv6 micro BFD会话保持正常，则可能仅从IPv4负载平衡表中删除成员链路；该链接可能仍处于活动状态
the IPv6 load-balancing table. Alternatively, the member link may be removed from both the IPv4 and IPv6 load-balancing tables. This decision is an implementation detail.
IPv6负载平衡表。或者，可以从IPv4和IPv6负载平衡表中删除成员链路。该决定是一个实施细节。
This document does not introduce any additional security issues and the security mechanisms defined in [RFC5880] apply in this document.
本文件未介绍任何其他安全问题，[RFC5880]中定义的安全机制适用于本文件。
IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. IANA has changed the reference to [RFC7130].
IANA为链路聚合组（LAG）接口上的双向转发检测（BFD）分配了专用MAC地址01-00-5E-90-00-01（参见[RFC7042]）和UDP端口6784。IANA已将引用更改为[RFC7130]。
IANA has changed the registry for port 6784 to show the Assignee as [IESG] and the Contact as [BFD_Chairs]. The expansion of [BFD_Chairs] is shown as "mailto:bfd-chairs@tools.ietf.org". IANA has changed the reference to [RFC7130].
IANA已更改6784端口的注册表，将受让人显示为[IESG]，联系人显示为[BFD_]。[BFD_Chairs]的扩展显示为“mailto:BFD”-chairs@tools.ietf.org". IANA已将引用更改为[RFC7130]。
We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky, and Jeff Tantsura for their comments.
我们要感谢Dave Katz、Alexander Vainstein、Greg Mirsky和Jeff Tantsura的评论。
The initial event to start the current discussion was the distribution of "Bidirectional Forwarding Detection (BFD) for Interface" (July 2011).
开始当前讨论的最初事件是分发“接口双向转发检测（BFD）”（2011年7月）。
Paul Hitchen BT EMail: paul.hitchen@bt.com
保罗·希钦BT电子邮件：保罗。hitchen@bt.com
George Swallow Cisco Systems EMail: swallow@cisco.com
George Swallow Cisco Systems电子邮件：swallow@cisco.com
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim亨德里克斯阿尔卡特朗讯电子邮件：Wim。henderickx@alcatel-朗讯网
Nobo Akiya Cisco Systems EMail: nobo@cisco.com
Nobo Akiya Cisco Systems电子邮件：nobo@cisco.com
Neil Ketley Cisco Systems EMail: nketley@cisco.com
Neil Ketley Cisco Systems电子邮件：nketley@cisco.com
Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com
Carlos Pignataro Cisco Systems电子邮件：cpignata@cisco.com
Nitin Bahadur Bracket Computing EMail: nitin@brkt.com
Nitin Bahadur计算电子邮件：nitin@brkt.com
Zuliang Wang Huawei Technologies EMail: liang_tsing@huawei.com
王祖良华为技术电子邮件：liang_tsing@huawei.com
Liang Guo China Telecom EMail: guoliang@gsta.com
梁国中国电信邮箱：guoliang@gsta.com
Jeff Tantsura Ericsson EMail: jeff.tantsura@ericsson.com
Jeff Tantsura Ericsson电子邮件：Jeff。tantsura@ericsson.com
[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月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年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月。
[IEEE802.1AX] IEEE Std. 802.1AX, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", November 2008.
[IEEE802.1AX]IEEE标准802.1AX，“局域网和城域网的IEEE标准-链路聚合”，2008年11月。
[RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042]Eastlake，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，2013年10月。
If the BFD-over-LAG feature were provisioned on an aggregated link member after the link was already active within a LAG, BFD session state should not influence the load-balancing algorithm until the BFD session state transitions to Up. If the BFD session never transitions to Up but the LAG becomes inactive, the previously documented procedures would then normally apply.
如果在链路在延迟内已处于活动状态之后，在聚合链路成员上设置了BFD over LAG功能，则BFD会话状态不应影响负载平衡算法，直到BFD会话状态转换为Up。如果BFD会话从未转换为Up，但滞后变为非活动状态，则之前记录的程序将正常适用。
This procedure ensures that the sequence of events -- enabling the LAG and enabling BFD on the LAG -- has no impact on the forwarding service.
此过程确保事件序列（启用滞后和在滞后上启用BFD）对转发服务没有影响。
If the BFD-over-LAG feature were deprovisioned on an aggregate link member while the associated micro-BFD session was in Up state, BFD should transition its state to AdminDown and should attempt to communicate this state change to the peer.
如果在关联的micro BFD会话处于Up状态时，在聚合链接成员上取消了BFD过滞后功能，则BFD应将其状态转换为AdminDown，并应尝试将此状态更改传达给对等方。
If the local or the remote state of a micro-BFD session is AdminDown, the system should not indicate a connectivity failure to any client and should not remove the particular LAG member link from forwarding. This behaviour is independent from the use of Link Aggregation Control Protocol (LACP) for the LAG.
如果micro BFD会话的本地或远程状态为AdminDown，则系统不应指示任何客户端的连接故障，也不应从转发中删除特定的LAG成员链接。这种行为独立于链路聚合控制协议（LACP）对延迟的使用。
When traffic is forwarded across a link while the corresponding micro-BFD session is not in Up state, an implementation may use a configurable timeout value after which the BFD session must have reached Up state otherwise the link is taken out of forwarding.
当在相应的micro BFD会话未处于启动状态时通过链路转发通信量时，实现可以使用可配置的超时值，在此值之后BFD会话必须已达到启动状态，否则链路将停止转发。
When such timeout values exist, the configuration must allow the ability to turn off the timeout function.
当存在此类超时值时，配置必须允许关闭超时功能。
The configurable timeout value shall ensure that a LAG is not remaining forever in an "inconsistent" state where forwarding occurs on a link with no confirmation from the micro-BFD session that the link is healthy.
可配置的超时值应确保延迟不会永远处于“不一致”状态，即在没有micro BFD会话确认链路健康的情况下，在链路上发生转发。
Note that if one device is not operating a micro-BFD session on a link, while the other device is and perceives the session to be Down, this will result in the two devices having a different view of the status of the link. This would likely lead to traffic loss across the LAG. The use of another protocol to bootstrap BFD can detect such mismatched config, since the side that's not configured can send a rejection error. Such bootstrapping mechanisms are outside the scope of this document.
请注意，如果一个设备未在链路上运行micro BFD会话，而另一个设备正在运行并感知到会话已关闭，这将导致两个设备对链路状态的看法不同。这可能会导致整个滞后期间的交通损失。使用另一个协议引导BFD可以检测到这种不匹配的配置，因为未配置的一方可能会发送拒绝错误。此类引导机制不在本文档的范围内。
Authors' Addresses
作者地址
Manav Bhatia (editor) Alcatel-Lucent Bangalore 560045 India
Manav Bhatia（编辑）阿尔卡特朗讯班加罗尔560045印度
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com
Mach(Guoyi) Chen (editor) Huawei Technologies Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China
中国北京市海淀区北青路156号华为校园华为技术Q14（编辑）Mach（郭毅）Chen 100095
EMail: mach@huawei.com
EMail: mach@huawei.com
Sami Boutros (editor) Cisco Systems
萨米·布特罗斯（编辑）思科系统公司
EMail: sboutros@cisco.com
EMail: sboutros@cisco.com
Marc Binderberger (editor) Cisco Systems
Marc Binderberger（编辑）思科系统
EMail: mbinderb@cisco.com
EMail: mbinderb@cisco.com
Jeffrey Haas (editor) Juniper Networks
Jeffrey Haas（编辑）Juniper Networks
EMail: jhaas@juniper.net
EMail: jhaas@juniper.net