Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017)

[Greg Mirsky <[e-mail]>]

Hi Manav,
I agree that it would be helpful to discuss whether using BFD to monitor
Layer 2 connectivity is the right approach. I'd point that from the Layer 2
perspective uBFD is not following the same fast path processing as data
packets either. Thus there could be some scenarios when uBFD produces
either false negative or false positive results. And while we understand
that, we agreed that these are rather exceptions and that uBFD is useful to
monitor constituent links. I believe it is reasonable to have the same
discussion about monitoring constituent links of a MC-LAG. Is it the
problem that needs to be solved? Do these drafts that propose to extend use
of uBFD offer technically reasonable solution? These are the questions, per
my understanding of WG adoption call, that we have in front of us.

Regards,
Greg

On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia <[e-mail]> wrote:

> Then BFD is not the right tool. You should use/invent something else.
>
> Cheers, Manav
>
> --
> Sent from a mobile device
>
> On Apr 18, 2017 8:47 AM, "Greg Mirsky" <[e-mail]> wrote:
>
> Hi Manav,
> single-hop BFD is helpful when the two BFD peers have Layer 2 switched
> domain between them. If the nodes are connected by the single wire, then
> there's no apparent benefit of using BFD at all. The same is the case for
> these two drafts. BFD is not intended to verify whether forwarding tables
> are correlating with the routing tables but it is to verify that a path
> exists between the BFD peers. In the case we've considered, the path
> through the Layer 2 switched domain. Thus I don't see that traversing the
> same blocks in fast path processing on the end nodes of the single-hop IP
> link is the critical requirement. But if the working group agrees that it
> is, then we'll be glad to work together to confirm with such requirement.
>
> Regards,
> Greg
>
> On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <[e-mail]>
> wrote:
>
>> I had raised the exact same concerns when this draft was originally
>> posted. So I concur with what Carlos says.
>>
>> Cheers, Manav
>>
>> --
>> Sent from a mobile device
>>
>> On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" <
>> [e-mail]> wrote:
>>
>> Jeff and Reshad,
>>
>> I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01
>> or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.
>>
>> The overall problem and proposed solution did not seem to have received
>> much discussion. I was only able to find one email thread on the list, over
>> a year ago.
>>
>> Regarding the problem statement, it’s strange that there’s no normative
>> definition or anything to MG-LAG… further, the meeting notes from IETF96
>> say things like:
>>           John Messenger: Would suggest work done in 802.1 to analyze
>> those
>>           considerations with 802, it would be necessary to coordinate to
>> work
>>           with them. Send a mail to IETF-IEEE802 coordination group.
>>           Jeff Haas: Can we sign you as a reviewer to this draft?
>>
>> What is the problem again, beyond what’s already well specified in RFC
>> 7130? Is this again a quick “solution” looking for an RFC number?
>>
>> Regarding the proposed solution, the one email thread seems to have
>> pointed out some serious issues not considered:
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg
>>
>> Additionally, why the split into two drafts for this? The text of both
>> documents overall seems forgotten, even sloppy, with many typos (“MPSL”,
>> “Indvidual”, etc), and copy/paste text between the two documents. The
>> complete Introduction and Problem Statement are verbatim copy/paste, and
>> include things like:
>>
>>   This document
>>    proposes how to overcome this problem if using IP or Multi-Protocol
>>    Label Switching (MPLS) data plane encapsulation.
>>
>> which is not the case for either document.
>>
>> Technically, using multicast here exercises a different path, and using a
>> GAL does as well. What are we testing?
>>
>> Net-net, do not support.
>>
>> Thanks,
>>
>> — Carlos.
>>
>> On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <[e-mail]> wrote:
>>
>> Working Group,
>>
>> https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00
>> https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/
>>
>> The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP
>> and MPLS have requested BFD working group adoption for their drafts.
>>
>> These drafts were previously presented at IETF-96.
>>
>> Please note that IPR has been declare against these drafts.  The IPR
>> declaration may be found from the datatracker links.
>>
>> Please indicate your support/lack of support to the mailing list.
>>
>> -- Jeff and Reshad
>>
>>
>>
>>
>>
>
>