Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Manav Bhatia <manavbhatia@gmail.com> Sat, 09 April 2016 09:08 UTC

Return-Path: <manavbhatia@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875712D158; Sat, 9 Apr 2016 02:08:23 -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 KNXkhRvEo2Dp; Sat, 9 Apr 2016 02:08:21 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 6660412D13B; Sat, 9 Apr 2016 02:08:21 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id o66so68779002ywc.3; Sat, 09 Apr 2016 02:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=aXEodagEAT415mNdSGV5iOy2Jo+FoN6VWbtqUUpmnC95up7x9xYrNkxjHPwVGPY/Tl h18Gp0aHnDoBvHNlGPXq7YXYFLmU/1mTyFq8xhrZTf8A/il+KmFeVDcceUAI3DgEtQRK wXB3MZ2IKNHQIDUdkE4gUv8DQ36AuIennHpkQwQQxiOdoXjRG7sMF6lQ9BZcLlg0XHY2 DURRj0aZoF3fOUzYoslwNfrhTYm5aPDvoReyDwht+USLhEDcQP3moc2U/YXd6rQlva/a Q043hgscylUnk9kjgqMdIaKlwTJthmA6rdn9/rS0IWy1tpUFtZSwOkxaxJP4l1+9TWFg fbpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=j2SOZ9fED86dHuCZenzsCUrPtAjDINQ+JURYVklQRoJcZMB9jBRvpyYqlaxdAfRlW7 bcifu2tW85wZZ6FUq/oCo2kvdn5jhkPw5q4d0yxfmNhazhGGI1klnrVrLAzm3WQ5fn0J DQOkHXkrQgOlBNa9Q9kL+M9lY2Gw1SMct6EGBNPNsE2b9H3N5zswmhfU0ZJtit5XNq60 qaFmdsZtEHINL/14yuCCPjf9MbFfzoMc2/ISiU+fod5CtsS03lrdE8UxAvJ/tKXblLIR rghRjJCJUbIzEZ8UQxN4RuApVWXdddOpyVcpz/ebnC7BkcDQCaR39+LOzjOm9gmE+UbG N1kg==
X-Gm-Message-State: AD7BkJLjqAMNu46oUPnJoUQESGp/v9UuIuFfDAPNXT+gYxL6sDhfcwvFVeq/BuXOaRFymV+3VR9rYzirHZhiUQ==
MIME-Version: 1.0
X-Received: by 10.129.70.70 with SMTP id t67mr6357220ywa.6.1460192900595; Sat, 09 Apr 2016 02:08:20 -0700 (PDT)
Received: by 10.13.216.3 with HTTP; Sat, 9 Apr 2016 02:08:20 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040F@SZXEMA510-MBX.china.huawei.com> <CAG1kdojp7Km16YDiwjvPKwRNjbvBWOkqpccRsEDCn8Q8BuV0Qg@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <CAG1kdoibVBWsga3K88MGbZAFSbD_2q0efea_8aEKd_hN+CV53w@mail.gmail.com> <D32D4A99.13B056%rrahman@cisco.com> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> <CAG1kdohiKMbE7bo2hFRncvdzEd-e7ekOE83Yw6Tk60q5ni6NRQ@mail.gmail.com> <CA+RyBmURRZa8eGNEqD-5sDq2HFX91WoOXxanO9qk0fOgVVT9LA@mail.gmail.com> <CAG1kdohntJQZT6947xk4+YGEhhNT_hVJqzxAwR6=yRuuaDLn4A@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se>
Date: Sat, 9 Apr 2016 14:38:20 +0530
Message-ID: <CAG1kdoh3jvvMmN5aYiQ17vpLQ-oUPOp9sTksjSPkNB=tyLxDQQ@mail.gmail.com>
From: Manav Bhatia <manavbhatia@gmail.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Content-Type: multipart/alternative; boundary=001a114d71ce24c89b053009a715
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/sFEHOGme2RpMsrbAWi-F6VIpdDM>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Reshad Rahman \(rrahman\)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2016 09:08:23 -0000

Hi Greg,

There is a difference, a big one.

When you use CFM or some other L2 OAM protocol, you dont make any claims
about L3 connectivity. However, when you start using BFD it implicitly
means that youre talking about L3 connectivity. So, its going to be bizarre
debugging complex topologies where BFD sessions never flap and yet MPLS
LSPs randomly time out (because there is this one MC-LAG thats dropping
packets -- and in the worst case, only sporadically and intermittently
drops IP packets)

It will NOT produce false negatives (as you claim) but rather introduce
false positives, which is more dangerous. The MC-LAG will be up, while it
would be dropping all or few IP packets.

I have no objections if operators and the community think that this is
something that they can live with. I am personally having an out-of-body
experience just discussing this! :-)

Cheers, Manav

On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky <gregory.mirsky@ericsson.com>
wrote:

> Hi Manav,
>
> the use case for the BFD over MC-LAG interfaces that I consider the most
> important for this drafts to address is to enable sub-second defect
> detection in order to trigger LACP convergence and, subsequently,
> switchover within the Redundancy Group in Active-Standby case. Hence both
> unicast and multicast L3 addresses are quite distant from L2 fast path and
> processing usually taken by CCM frames. Of course, one can use CFM per LAG
> Constituent Link, and I have implemented that and it interoperates with
> another implementation by other vendor, but operators prefer ease of BFD
> provisioning. Thus I’ve to provide them with ability to monitor MC-LAG and
> explain that in some cases it may produce false negative when L2 is
> functional and the problem is in L3, unicast or multicast, engine. As you
> can see, there’s not much value in continuing argument how much different
> L3 multicast processing is from L3 unicast as both are different from L2
> path. At the end, as I think, it is up to operators to decide whether they
> are comfortable with this mechanism or would require defect detection at L2.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com]
> *Sent:* Friday, April 08, 2016 5:38 PM
> *To:* Greg Mirsky
> *Cc:* Reshad Rahman (rrahman);
> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org;
> mpls-chairs@ietf.org; mpls@ietf.org; rtg-bfd-chairs@ietf.org; Gregory
> Mirsky
> *Subject:* Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> Hi Greg,
>
>
>
> the update could be in addition of either broadcast or link local
> multicast or both with appropriate normative language. But I would not
> agree that these wouldn't work.
>
>
>
> Double negatives make it very hard to parse a sentence.
>
>
>
> Anyway, why would you NOT agree that this WOULDNT work?
>
>
>
> I am telling you that link local multicasts and unicasts are dealt with
> differently in the data plane, so the data path being up for the former may
> not necessarily mean that its up for the latter as well. So tell me WHY you
> think this argument isnt valid? I was the L3 data plane architect in my
> former company for one of the product lines and i am telling you that in my
> box, which is very very widely deployed, your scheme will NOT work since i
> punt all link local packets to the CPU differently. In fact, in some cases
> even the TX path is different. So sure, u-BFD may very well claim that the
> link is up, but its possible that there may be no IP connectivity.
>
>
>
> Cheers, Manav
>
>
>