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

[Gregory Mirsky <[e-mail]>]

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

    Regards,
        Greg

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

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.

 GIM>> Absolutely.

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).

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

(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).

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

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?

GIM>> No MUST or SHOULD in Section 3.


Thanks & Regards,
Marc



On 2013-05-20, at 23:29 , Gregory Mirsky wrote:

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, May 10, 2013 3:14 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt


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/