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

[Marc Binderberger <[e-mail]>]

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 or lack of thereof is result of particular implementation desicions.

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




On 2013-05-21, at 21:04 , 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/
>>  
>>  
> 
>