Skip to main content

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
draft-ietf-bfd-on-lags-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    bfd mailing list <rtg-bfd@ietf.org>,
    bfd chair <bfd-chairs@tools.ietf.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/


Ballot Text

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.

RFC Editor Note