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

Gregory Mirsky <gregory.mirsky@ericsson.com> Sat, 09 April 2016 22:32 UTC

Return-Path: <gregory.mirsky@ericsson.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 6075A12D18D; Sat, 9 Apr 2016 15:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 HYIyqg2V90Uv; Sat, 9 Apr 2016 15:32:52 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C7112D175; Sat, 9 Apr 2016 15:32:51 -0700 (PDT)
X-AuditID: c618062d-f79216d00000767f-d2-57097cb47ba4
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.49.30335.4BC79075; Sun, 10 Apr 2016 00:05:40 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sat, 9 Apr 2016 18:32:49 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Manav Bhatia <manavbhatia@gmail.com>
Thread-Topic: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4P//39qAgAAYVICAAF4BgIAACP5QgACFuwD//2O6MA==
Date: Sat, 9 Apr 2016 22:32:48 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A4146E@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> <CAG1kdoh3jvvMmN5aYiQ17vpLQ-oUPOp9sTksjSPkNB=tyLxDQQ@mail.gmail.com>
In-Reply-To: <CAG1kdoh3jvvMmN5aYiQ17vpLQ-oUPOp9sTksjSPkNB=tyLxDQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyuXSPt+6WGs5wg9+HtS0ObDrIaPFt2lNW i8uT2tgt1l0+xWZxa+lKVotrK1rZLT7/2cbowO4x5fdGVo+ds+6yeyxZ8pPJ48vlz2wBLFFc NimpOZllqUX6dglcGQd+NDEW/NvNWLHz6VymBsaG7YxdjBwcEgImEv2z5LoYOYFMMYkL99az dTFycQgJHGWU+L/7HzOEs4xRYvbyn4wgVWwCRhIvNvawg9giAhoSre8PgBUxC+xiknh24zML SEJYwEPi9oIJrBBFnhKbX52Fsuskdv3rYQKxWQRUJFZfP8sMYvMK+ErMu3+VFWLbVjaJfQcv gxVxCgRK9F9bCNbMCHTf91NrwOLMAuISt57MZ4K4W0BiyZ7zzBC2qMTLx/9YIWwliY+/57ND 1OdLfLt3kR1imaDEyZlPWCYwis5CMmoWkrJZSMpmAUOJWUBTYv0ufYgSRYkp3Q/ZIWyg/+fM ZUcWX8DIvoqRo7S4ICc33chgEyMwQo9JsOnuYLw/3fMQowAHoxIPb0I1Z7gQa2JZcWXuIUYJ DmYlEd5IkBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHexuB/YUIC6YklqdmpqQWpRTBZJg5OqQZG ib27rFYbRvmI7n7afYPp65HwCQb5i/f9sXG4WSL7ojdgnZytmP4j5ovXCpgn+R163hkgvlKc +eLCA0fj5yQezs0RXPPnLYtP1oazE1XZt+lIPcj5+Lj0qfNmrxUz8qffKi8OXHNO4Grat+q3 r2N+Zn1N0JCQW3bXePred5VHip9pxRi9i2h+p8RSnJFoqMVcVJwIAOs/pCHMAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/D88yPCl72OH6lgY8dIiWmZh5ijk>
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 22:32:54 -0000

Hi Manav,
I’m glad that we’re converging – the final decision would come from our customers, the operators.
I hope we’ll have their comments.
In the meantime, I invite you and other experts to review the second draft that looks into the same scenario but over the IP/MPLS network. It may be less controversial as neither multicast, nor broadcast addresses need to be used as the destination IP address.

                Regards,
                                Greg

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Saturday, April 09, 2016 2:08 AM
To: Gregory Mirsky
Cc: Greg Mirsky; Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

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<mailto: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<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<mailto:draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; rtg-bfd-chairs@ietf.org<mailto: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