Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, bfd mailing list <email@example.com>, bfd chair <firstname.lastname@example.org> Subject: Protocol Action: 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces' to Proposed Standard (draft-ietf-bfd-on-lags-04.txt) The IESG has approved the following document: - 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces' (draft-ietf-bfd-on-lags-04.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/
Technical Summary This document defines a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. Working Group Summary The blurred line between L2 and L3 initiated several interesting discussions. Is it a layer violation for BFD operating at layer 3 to make layer 2 decision? How does it interact with LACP? How does it influence LAG member link usability? The desire and need for rapid detection of LAG member link usability, as well as similar solutions already implemented by multiple vendors, resulted in consensus to push this technology forward. The WG was satisfied with very careful wordings of the document to ensure that solution does not tread on IEEE turf. In addition, remote IP address discovery was a controversial topic. There were multiple ideas to do this dynamically, on which the WG couldn't reach consensus. Thus this aspect was taken out into a separate draft.That spin-off draft died, since people lost interest due to statically configuring remote IP address working good enough. Document Quality There are multiple implementations of the protocol. An event was held to interoperate the implementations. The document has been reviewed through the normal WG process. No MIB Doctor, Media Type or other expert review been performed or requested. Personnel Nobo Akiya is the document Shepherd. Adrian Farrel is the responsible AD.