[要約] RFC 7130は、リンク集約グループ（LAG）インターフェース上での双方向転送検出（BFD）に関する規格です。このRFCの目的は、LAGインターフェース上でのBFDの実装と運用に関するガイドラインを提供することです。
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.
このメカニズムにより、Link Aggregation Control Protocol（LACP）と組み合わせて、またはリンクアグリゲーションコントロールプロトコル（LACP）がない場合のメンバーリンクの連続性を検証できます。 LACPが提供するものよりも短い検出時間を提供します。導通チェックは、レイヤ3（L3）双方向転送の要素もカバーできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]は、インターフェイス、データリンクを含む2つのフォワーディングエンジン間の双方向パスの障害を検出するメカニズムを提供します。可能な限り、非常に低いレイテンシでフォワーディングエンジン自体を検出します。また、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 of the physical member links fails, the aggregate logical link can continue to forward traffic over the remaining operational physical member links.
[IEEE802.1AX]で定義されているLAGは、複数の物理リンクを単一の論理リンクに結合するメカニズムを提供します。この論理リンクは、物理メンバーリンクの1つに障害が発生した場合でも、集約論理リンクが動作可能な残りの物理メンバーリンクを介してトラフィックを転送し続けることができるため、より高い帯域幅とより優れた復元力を提供します。
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セッションを実行し、LACPの有無にかかわらず、LAGメンバーリンクをLAGインターフェイスのL2ロードバランシングテーブルの一部にするかどうかをBFDで制御することです。 。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
LAGメンバーリンクの障害を迅速に検出するために定義されているメカニズムは、すべてのLAGメンバーリンクで非同期モードの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.
メンバーリンクマイクロBFDセッションは、IP / UDPカプセル化を使用する場合、IPv4またはIPv6アドレスを使用できます。メンバーリンクごとに2つのマイクロBFDセッションが存在する場合があります。1つはIPv4、もう1つはIPv6です。アドレスファミリが1つのメンバーリンクで使用される場合、特定のLAGのすべてのメンバーリンクで使用される必要があります。
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].
LAGの各メンバーリンクで、有効になっているすべてのアドレスファミリの単一のマイクロBFDセッションが実行されます。マイクロ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エコー機能の使用は、このドキュメントの範囲外です。少なくとも1つのシステムがアクティブな役割（おそらく両方）を取る必要があります。メンバーリンク上のマイクロBFDセッションは、独立したBFDセッションです。それらは、独自のローカルの識別値を使用し、独自の状態変数のセットを維持し、独自の独立した状態マシンを持っています。同じ集約に属するマイクロBFDセッションは同じタイマー値を使用することが予想されますが、同じ集約に属するマイクロ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パケットの逆多重化は、このフィールドがゼロ以外の場合、Your Discriminatorフィールドにのみ基づいています。 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制御パケットの受信手順は、LAGメンバーリンクのマイクロ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フィールドがゼロ以外で、LAGセッション上のマイクロBFDが見つかった場合、マイクロ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ポートにより、シングルホップIP上のBFDからBFD over LAGパケットのあいまいさが取り除かれます。例は、片側のマイクロBFDセッションでLAGを（誤って）構成していますが、反対側のLAG（単一のインターフェースとして扱われる）に[RFC5881] BFDセッションを使用しています。
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メッセージに使用する必要があり、他のBFDモードを説明するRFCに割り当てられている他のポートには使用してはなりません。
Control packets use a destination IP address that is configured on the peer system and can be reached via the LAG interface.
制御パケットは、ピアシステムで構成され、LAGインターフェイス経由で到達できる宛先IPアドレスを使用します。
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です。この専用MACアドレスは、Down / AdminDownおよびInit状態のときに、マイクロBFDセッションの初期BFDパケットに使用する必要があります。マイクロBFDセッションがアップ状態に変化するとき、アップ状態の最初の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アドレスを使用して、アップ状態の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アドレスにする必要があります（SHOULD）。
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パケットは常にタグなしで送信する必要があります（SHOULD）。ただし、LAGがIEEE 802.1qまたはIEEE 802.qinqのコンテキストで動作している場合、micro-BFDパケットはタグなしであるか、ゼロのVLANタグ（802.1p優先度タグ付き）で送信されます。この標準に準拠した実装は、タグなしと802.1pの両方の優先度タグ付きマイクロBFDパケットを受信できなければなりません（MUST）。
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.
メンバーリンクの状態がDistributingまたはStandbyの場合、特定のLAGメンバーリンクのマイクロ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は、負荷分散アルゴリズムが特定のLAGメンバーリンクを選択できるかどうかを制御するために使用されます。言い換えると、リンク集約制御プロトコル（LACP）が使用され、メンバーリンクがトラフィックを転送する準備ができていると見なした場合でも、特定のメンバーリンクのすべてのマイクロBFDセッションまで、メンバーリンクをロードバランサーで使用してはなりません（MUST NOT）アップ状態です。
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セッションに基づく負荷分散アルゴリズムでメンバーリンクを有効にすることができます（MAY）。一致するアドレスファミリのみ。
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パケット自体です。実装は、セッション状態に関係なく、Aggregatorの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プロトコルは、LAGについての洞察がなく、それを1つの大きなインターフェイスとして扱います。マイクロセッションからL3プロトコルへのシグナリングは、ロードバランシングテーブルに対するマイクロBFDセッションの影響と、LAGをシャットダウンするというインターフェイス/ LAG管理モジュールの潜在的な決定によって効果的に行われます。マイクロBFDセッションの影響をテストするアクティブな方法は、L3プロトコルがLAGごとに単一のBFDセッションを要求することです。
When a micro-BFD session goes down, this member link MUST be taken out of the LAG load-balancing table(s).
マイクロBFDセッションがダウンした場合、このメンバーリンクをLAGロードバランシングテーブルから削除する必要があります。
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 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.
実装にIPv4とIPv6の個別の負荷分散テーブルがある場合、IPv4とIPv6の両方のマイクロBFDセッションがメンバーリンクに存在する場合、実装はアドレスに一致する負荷分散テーブルからのみメンバーリンクを削除できます（MAY）失敗したBFDセッションのファミリ。たとえば、IPv4マイクロBFDセッションは失敗しますが、IPv6マイクロBFDセッションはアップのままです。その後、メンバーリンクはIPv4ロードバランステーブルからのみ削除される場合があります。リンクは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は、専用のMACアドレス01-00-5E-90-00-01（[RFC7042]を参照）と、リンクアグリゲーショングループ（LAG）インターフェイス上の双方向転送検出（BFD）用の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_Chairs]として表示します。 [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 Vainshtein、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メール：paul.hitchen@bt.com
George Swallow Cisco Systems EMail: swallow@cisco.com
ジョージスワローシスコシステムズメール：swallow@cisco.com
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucentメール：wim.henderickx@alcatel-lucent.com
Nobo Akiya Cisco Systems EMail: nobo@cisco.com
のぼ あきや しｓこ Ｓｙｓてｍｓ えまいｌ： のぼ＠しｓこ。こｍ
Neil Ketley Cisco Systems EMail: nketley@cisco.com
Neil Ketley Cisco Systems EMail：nketley@cisco.com
Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com
Carlos PignataroシスコシステムズEメール：cpignata@cisco.com
Nitin Bahadur Bracket Computing EMail: nitin@brkt.com
Nitin Bahadur Bracket Computing Eメール：nitin@brkt.com
Zuliang Wang Huawei Technologies EMail: liang_tsing@huawei.com
Z Uliang Wang hu Aはテクノロジーメールです：Two_Exploring@Huawei.com
Liang Guo China Telecom EMail: guoliang@gsta.com
l Ian GG UO Chinaテレコムメール：Overdose @古斯塔.com
Jeff Tantsura Ericsson EMail: jeff.tantsura@ericsson.com
ジェフタンツラエリクソンEメール：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、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年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 5881、2010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882] Katz、D。およびD. Ward、「Generic Application of Bidirectional Forwarding Detection（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 Std。 802.1AX、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、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、「IANAの考慮事項およびIEEE 802パラメータの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.
BAG-over-LAG機能がリンクがLAG内ですでにアクティブになった後で集約リンクメンバーにプロビジョニングされた場合、BFDセッション状態がUpに移行するまで、BFDセッション状態はロードバランシングアルゴリズムに影響を与えません。 BFDセッションがUpに移行しないが、LAGが非アクティブになる場合、以前に文書化された手順が通常適用されます。
This procedure ensures that the sequence of events -- enabling the LAG and enabling BFD on the LAG -- has no impact on the forwarding service.
この手順により、イベントのシーケンス（LAGの有効化とLAGでの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.
関連付けられたマイクロBFDセッションがアップ状態のときに、BFD-over-LAG機能が集約リンクメンバーでプロビジョニング解除された場合、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.
マイクロBFDセッションのローカルまたはリモートの状態がAdminDownである場合、システムはクライアントへの接続障害を示してはならず、特定のLAGメンバーリンクを転送から削除してはなりません。この動作は、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.
対応するマイクロ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.
構成可能なタイムアウト値は、リンクが正常であるというマイクロBFDセッションからの確認なしでリンク上で転送が発生する「不整合」状態でLAGが永久に残ることを確実にします。
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.
1つのデバイスがリンク上でマイクロBFDセッションを操作していないときに、もう1つのデバイスがセッションをダウンしていると認識している場合、リンクのステータスの表示が2つのデバイスで異なることに注意してください。これにより、LAG全体でトラフィックが失われる可能性があります。別のプロトコルを使用してBFDをブートストラップすると、設定されていない側が拒否エラーを送信する可能性があるため、このような不一致の設定を検出できます。このようなブートストラップメカニズムは、このドキュメントの範囲外です。
Authors' Addresses
著者のアドレス
Manav Bhatia (editor) Alcatel-Lucent Bangalore 560045 India
Manav Bhatia（editor）アルカテルルーセントバンガロールインド560045
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
Mach（GU O一）Chen（編集者）hu AはテクノロジーQ14 hu Aはキャンパス、第156 be i青路、hラブドット地区北京100095中国
EMail: mach@huawei.com
Sami Boutros (editor) Cisco Systems
Sami Boutros（編集者）Cisco Systems
EMail: sboutros@cisco.com
Marc Binderberger (editor) Cisco Systems
Marc Binderberger（editor）Cisco Systems
EMail: mbinderb@cisco.com
Jeffrey Haas (editor) Juniper Networks
ジェフリー・ハース（編集者）ジュニパーネットワークス
EMail: jhaas@juniper.net