Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt

From: [email-masked]
Date: Fri, 10 May 2013 15:13:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
	Author(s)       : Manav Bhatia
                          Mach(Guoyi) Chen
                          Sami Boutros
                          Marc Binderberger
                          Jeffrey Haas
	Filename        : draft-ietf-bfd-on-lags-00.txt
	Pages           : 11
	Date            : 2013-05-10

Abstract:
   This document proposes 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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 May 2013 18:16:23 -0400

Finally, we have the draft as draft-ietf-bfd!

The draft represents consensus to date.  Please give the document some of
your time for review.

Also, authors, please make a positive acknowledgement to the mailing list as
to whether you are aware of any IPR against this draft.

-- Jeff

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 11 May 2013 06:45:37 +0000

I am not aware of IPR against this draft

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 11 May 2013 20:06:59 +0000

Hi,

I'm not aware of any IPR.

Thanks!

Cheers,
Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 May 2013 12:18:52 -0400

> to whether you are aware of any IPR against this draft.

Chiming in as an author, I am not personally aware of any intellectual
property restrictions on this draft.

-- Jeff

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 14 May 2013 00:03:48 +0000

Same here.

Cheers, Manav 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, May 13, 2013 9:49 PM
> To: Jeffrey Haas
> Cc: [email-masked]
> > Also, authors, please make a positive acknowledgement to 
> the mailing 
> > list as to whether you are aware of any IPR against this draft.
> 
> Chiming in as an author, I am not personally aware of any 
> intellectual property restrictions on this draft.
> 
> -- Jeff
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 20 May 2013 21:29:04 +0000

Dear Authors, et al.,
I agree with everything in the latest version of the document but inclusion of Section 3. I think that what is discussed in the section and use of normative language are outside of the scope of BFD WG charter:
Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces.

Content of the section seems more suitable as Informational or BCP with appropriate changes in use and interpretation of RFC 2119 language.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 10, 2013 3:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt

Abstract:

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 21 May 2013 00:53:37 +0200

Hello Greg,

thanks for your feedback!

Hmm. It's true that section 3.2 is not necessary to get BFD on lags flying, it is about details implementors should consider. We are actually discussing section 3.2 and plan to simplify the text and add explanations. Couple of days of text smithing, I hope, then we can extend the discussion to the list.

But 3.1 ... if we remove it then we run into interoperability problems:

(a) first BFD, then LACP up
(in other words: BFD does not depend on LACP but LACP depends on BFD)
(b) first LACP, then BFD up
(in other words: LACP does not depend on BFD but BFD depends on LACP)
(c) LACP and BFD are mutually independent

(a) and (b) are not interoperable. We had to make a choice. The consideration from the LAG experts was to use LACP (if enabled) to organize the LAG before starting BFD, i.e. solution (b).

Sure, we could have everyone sort it out themselves that the two allowed ways to influence the LAG

(A) BFD influences the per-port MAC operational flag
(B) BFD influences the load-balance algorithm

are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) cannot be combined. Instead we explicitly mentioned (B) is used, based on the decision for (b).

This is not BCP or informal, in my opinion.

Regarding the language: which aspects do you think are not acceptable to define a new standard and need to be changed? 

Thanks & Regards,
Marc

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 21 May 2013 19:04:42 +0000

Hi Marc,
thank you for most expedient response. Please find my notes in-lined and tagged with GIM>>,

    Regards,
        Greg

________________________________
From: Marc Binderberger [mailto:[email-masked]]
Sent: Monday, May 20, 2013 3:54 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt

Hello Greg,

 GIM>> Absolutely.

GIM>> You're concerned with LAG interoperability, not interoperability of micro-BFD as fully addressed without Section 3. Integration of micro-BFD and LACP is implementation issue. Interoperability or lack of thereof is result of particular implementation desicions.
Sure, we could have everyone sort it out themselves that the two allowed ways to influence the LAG

GIM>> I think that IETF document can stop at mapping BFD state machine to Actor Port states of IEEE 802.1AX.

GIM>> No MUST or SHOULD in Section 3.

Thanks & Regards,
Marc

Dear Authors, et al.,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, May 10, 2013 3:14 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt

Abstract:

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 May 2013 13:59:30 -0400

> Sure, we could have everyone sort it out themselves that the two allowed ways to influence the LAG

Operation of micro-BFD sessions with LAGs with LACP present is a task we are
required to resolve.  IEEE will have some nasty words for us if that is not
the case.

> (A) BFD influences the per-port MAC operational flag

We had previously decided to not do this since it put us a bit too deep into
state machines in other mechanisms.  Working in this space also gathered the
most concern from IEEE.  As you'd point out, the mac operational flag was
also their recommended mechanism to avoid meddling with LACP directly.

> (B) BFD influences the load-balance algorithm

This was our chosen path forward.  One point that pushed the authors in this
direction were a multitude of implementation specific issues wherein taking
the link out of service (a above) rather than simply updating the forwarding
behavior made things difficult.  Rather than walk the line of the protocol
purists to cover a, b permitted the greatest opportunity for
interoperability.

> GIM>> No MUST or SHOULD in Section 3.

The authors have some new text in that section in review and will be
desiring comments on it.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 24 May 2013 01:44:45 +0200

Hello Gregory,

thanks for your comments!

> GIM>> You're concerned with LAG interoperability, not interoperability of micro-BFD as fully addressed without Section 3. Integration of micro-BFD and LACP is implementation issue. Interoperability…

I understand your point of view but the draft is explicitly about BFD for LAG Interfaces.  A statement how BFD and LACP are supposed to interact should be part of a normative specification, especially as the lack thereof may cause interop problems.

> GIM>> No MUST or SHOULD in Section 3.

you mean MAY or really MUST ?

I see that section 3.2 is not necessary to get BFD on LAG working. On the other hand having one document describing the protocol work and some corner cases for implementor seems reasonable. What about moving 3.2 into an appendix "Notes for implementors" ?

First paragraph of 3.1 is not more than some context - we could remove it? Paragraph 2 describes the dependency between LACP and BFD. Paragraph 3, 4 and 5 describe how actually the influence on the LAG load balance function happens.

Best regards,
Marc