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

[Marc Binderberger <[e-mail]>]

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/
>>  
>>  
> 
> 
>