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

Manav Bhatia <manavbhatia@gmail.com> Tue, 18 April 2017 15:47 UTC

Return-Path: <manavbhatia@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667412EBCE for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Apr 2017 08:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAZvQTv6xTmm for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Apr 2017 08:46:59 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0B2120727 for <rtg-bfd@ietf.org>; Tue, 18 Apr 2017 08:46:59 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id b187so182261762oif.0 for <rtg-bfd@ietf.org>; Tue, 18 Apr 2017 08:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbmIazyz+BDpnV+Tl9eB0okm13YKIEeZ4ksMI6JTllM=; b=vh8wQWndogp7hVKahH68a4f8k/X3m9yth8ITbu62TDzLzP8P+44UVfjpyLdd8EH029 9c40mpQLJuBMy4mZ70TZKMf45o8dNqAatc8Ee9XB04fETqBfAyDFFAtE0XY/ELywkp05 chIKYB5anG3Y1Cv7UAzwRaqSt4rBeLVn10gGaf2Ei9Ypfoy4U6tYB2T7I/4nzdGmI6Lm nqNDv4wIFlwvCPcg4hQmCpKDeLyJdo5Fu4nNiTZvtEGy7bhsc8m8jTtgWDSAl3Uhub8F SN/xKSlETSXxTvxtgS3zW8V8yA/nonsG47Hm9q/aU/I6R6UFRi9N9/wbuavaXIK/9zLH S8mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bbmIazyz+BDpnV+Tl9eB0okm13YKIEeZ4ksMI6JTllM=; b=Xu25aLV5VmlTp9HnKYO73t+4V8chOFqw3vGgD5G+WdiJ2OJyPmlT6f1fN+w6SNj7wE FD6Cwp09/NXGvPyWfHKaUEdU9nlvUcCr/kO3oGPZhzbZsBgAeHbys8mFKG0hletvOTFR 886+W2qcUW/arXcISIJ1fI+dGWYcbQQJLwpw9yPt4hDGjL47DA2gzi/t1LIfsLe6cEha LC4C9wL7dgZwNSes4rHco7eFqrv4rWbyVBDM/gSq+qa3tevDnfwDA/RMcpD+p2CoKFEg 3tvG3w7KtWQMcvgHKihcesfK6T0TXgOWqBsIZ0eS4gPSrXuj2I3yNKq1k+nY22rZx6s+ 5XPg==
X-Gm-Message-State: AN3rC/7JF2li6pdlRLIpHKE7ThD9lRkypgEUNWHxjjr3hUkPTQZIkXWi dGt7jfIC6uii5x28ul6OJ8dzXau4Ng==
X-Received: by 10.202.225.212 with SMTP id y203mr6946358oig.46.1492530418807; Tue, 18 Apr 2017 08:46:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.56.45 with HTTP; Tue, 18 Apr 2017 08:46:58 -0700 (PDT)
Received: by 10.157.56.45 with HTTP; Tue, 18 Apr 2017 08:46:58 -0700 (PDT)
In-Reply-To: <CA+RyBmURLzo8nQY6=9BcEikbLKuBWe2jGDRS1ABCwU09bH02ZQ@mail.gmail.com>
References: <20170417225539.GE18219@pfrc.org> <B14F6006-540C-4590-91DF-4F434F571AC2@cisco.com> <CAG1kdojdYng7uEzaM-+v99UfSSWHu=_MaTz7xtxBi2i3KQHf_A@mail.gmail.com> <CAG1kdoi9+7remCa5akfE8C6ttmTGOOiR+Xne3P6nvnu+yWqYyw@mail.gmail.com> <CA+RyBmV3SYYK+PPc9V540iUfFphD=cZH010vAEPd+zu1+YvjyQ@mail.gmail.com> <CAG1kdoi5Kb83_KAj7cZYUcrkJt9-iC5KOr1WJsRGneCgNBn4wA@mail.gmail.com> <CA+RyBmURLzo8nQY6=9BcEikbLKuBWe2jGDRS1ABCwU09bH02ZQ@mail.gmail.com>
From: Manav Bhatia <manavbhatia@gmail.com>
Date: Tue, 18 Apr 2017 21:16:58 +0530
Message-ID: <CAG1kdog_HatwqWfhB-ZfoFBgT0=8C65mGDG09YTtZcACOZwxbw@mail.gmail.com>
Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017)
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd@ietf.org, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary="001a113d2dfe6dfb99054d72d145"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Y-VTVt2-u9G9J61MR0J2PsT4Ah4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 15:47:02 -0000

I don't know why you think ubfd packets do not follow the regular data path?

I am traveling and have sporadic Internet connectivity, so response can get
delayed.

--
Sent from a mobile device

On Apr 18, 2017 10:31 AM, "Greg Mirsky" <gregimirsky@gmail.com> wrote:

> 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 <manavbhatia@gmail.com>
> 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" <gregimirsky@gmail.com> 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 <manavbhatia@gmail.com>
>> 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)" <
>>> cpignata@cisco.com> 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-3zxG
>>> ZboTKVqUwSr6w
>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7Py
>>> JbpP-RVnVFMcQ
>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4
>>> UPB4buR0iyxcg
>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAA
>>> XyTof4ycq2DUg
>>>
>>> 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 <jhaas@pfrc.org> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>