[[e-mail]: New Liaison Statement, "In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG"]

[Jeffrey Haas <[e-mail]>]

Official response to the IEEE 802.1 group.

----- Forwarded message from Liaison Statement Management Tool <[e-mail]> -----

Date: Tue, 25 Sep 2012 13:55:02 -0700
From: Liaison Statement Management Tool <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: New Liaison Statement, "In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG"

Title: In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG
Submission Date: 2012-09-25
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1192/

From: Bidirectional Forwarding Detection (Jeffrey Haas <[e-mail]>)
To: IEEE 802.1 ([e-mail])
Cc: [e-mail],[e-mail],[e-mail]
Reponse Contact: 
Technical Contact: [e-mail],[e-mail]
Purpose: In response
Referenced liaison: Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG (http://datatracker.ietf.org/liaison/1152/)
Body: Dear Tony,

Thank you for your prompt response with regards to our liaison letter regarding
BFD over Ethernet LAGs.  The IETF BFD Working Group is happy to hear that IEEE
is willing to work with us in specifying the interworking of BFD over Ethernet
LAGs.  In particular, your response seems to provide good guidance in how we may
be able to draft a specification for BFD in this scenario.

After further consideration of our proposal, the authors of the BFD over
Ethernet LAG draft have largely decoupled the BFD functionality from LACP. When
using LACP for a LAG, BFD will monitor the fact that the LAG member link has
entered the Distributing state and use this transition to activate the BFD
session.

Furthermore, the BFD working group will not make any modifications to LACP, and
this work will not be used to influence the LACP state machine.  Our intent is
that BFD solely influences the traffic load balancer, an implementation detail
we believe is outside the scope of 802.1ax, to control whether traffic is sent
on a LAG member link or not.

With regard to your comment:


    "We must point out Link Aggregation is a (lower) Layer 2 construct, not a
     Layer 3 construct. It is not uncommon to connect a router to a bridge
     via an aggregated link. In this case, it is not clear how one uses a
     Layer 3 protocol to support the aggregation, or how to achieve
     interoperability when two different protocols are used (i.e. BFD and
     CFM) for the same purpose for the two connected systems."

the Working Group even at this early stage is in agreement with you.

The initial Internet-Draft (which at this stage is still not a working group
document) for BFD over Ethernet LAGs is currently intended to only address the
case where there is no bridging involved, and intended to operate over LAG
members that are each IP-capable links.  Some discussion has occurred among the
draft authors about BFD over Ethernet LAGs with bridges and we may pursue this
scenario at a later date, in which case we may discuss the details with you
further.

In the meantime, you can see the latest copy of the Internet-Draft at
http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/
Please be aware that the BFD working group is now considering adopting this
document as formally part of its work.

We look forward to continuing to work with you on this problem space.

Regards,
Jeffrey Haas, David Ward
IETF BFD Co-Chairs
Attachments:

No document has been attached

----- End forwarded message -----