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

[Gregory Mirsky <[e-mail]>]

Hi Marc, et. al,
Thank you for making me feel special by excluding from the "BFD experts" list ;-)
As you probably expected, I have couple comments to the latest version. And here they are:
*       Abstract correctly notes that distinct UDP port, to be allocated by IANA, for micro-BFD will simplify concurrent support of single-hop over LAG circuit and micro-BFD. I'll add that same can be said about scenario when micro-BFD to run concurrently with multi-hop BFD over LAG circuit.
   *    In the last paragraph on Introduction native Ethernet failure detection mechanisms listed as 802.1ax and .3ah. I think these should be 802.1ag and 802.3ah.
   *    Section 3. First sentense in the second paragraph confuses me. Would following be acceptable to authors "BFD can control whether a particular LAG member link can be used by the load distribution algorithm"?
   *    Same second paragraph in Section 3. I think that "MUST NOT" is too restrictive since problem might be not in the forwarder but benign mis-configuration. And this MUST NOT negated in the Appendix A for the case when micro-BFD session added after LACP determined the member link being Up. Perhaps it can be changed to "SHOULD NOT" and further explained that behavior must be consistent across all member links on both nodes. Control of this behavior is obviously outside of scope for this document.


        Regards,
                Greg

-----Original Message-----
From: Marc Binderberger [mailto:[e-mail]]
Sent: Thursday, June 13, 2013 1:42 AM
To: Gregory Mirsky
Cc: [e-mail]
Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt

Hello Gregory & BFD experts,

my apology, I forgot to publish the updated version. Happened now

   https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags

We have moved one section into the appendix, following your feedback that the particular section content is more a "best practise" than a standard definition. Section 3 (formerly 3.1) got a bit of a cleanup and we are more explicit now with the MUST/MAY/NOT wording to avoid confusion what we mean.


Best regards,
Marc




On Tue, 21 May 2013 19:04:42 +0000, Gregory Mirsky wrote:
> 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]] On
>> Behalf Of [e-mail]
>> Sent: Friday, May 10, 2013 3:14 PM
>> To: [e-mail]
>> Cc: [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/
>>
>>
>
>
>