RE: BFD stability follow-up from IETF-91

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 08 December 2014 05:46 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F281A6F17 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level:
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 qEHo8d0rSB8L for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:46:09 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428161A6EFB for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 21:46:09 -0800 (PST)
X-AuditID: c6180641-f79916d00000623a-7a-5484deae2925
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 42.1B.25146.EAED4845; Mon, 8 Dec 2014 00:11:43 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:46:07 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Marc Binderberger <marc@sniff.de>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAVyAD//7KYYA==
Date: Mon, 08 Dec 2014 05:46:07 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE6E8@eusaamb103.ericsson.se>
References: <CO2PR0501MB823C222B7D62779F4DF58CDB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <D0A647C1.28843%mmudigon@cisco.com> <CO2PR0501MB8234A1BDDFD008EE12C847AB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE38D@xmb-aln-x01.cisco.com> <CAG1kdogkUr2YyodeUPWOqea+2jqOkmdYnPywVHCw8j1+=9eM6A@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE4AE@xmb-aln-x01.cisco.com> <CAG1kdoh5DwdKrJWK_aSvo4KQ6Xu5ZaTObe_PLhV66YZ4yQozmg@mail.gmail.com> <20141207193610211284.1f098741@sniff.de> <CAG1kdojxdDY0qXPYnZ5K67rizVaD7gHte1MdRA2q==K6SoRVsw@mail.gmail.com> <20141207212102448099.e2e4012a@sniff.de>
In-Reply-To: <20141207212102448099.e2e4012a@sniff.de>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPt+76ey0hBsen8lrMvvKf2eLzn22M DkweS5b8ZPJoXd3NEsAUxWWTkpqTWZZapG+XwJVx+uJKpoK3ghXPpr5kaWDs5Oti5OSQEDCR 2Ll8PhuELSZx4d56IJuLQ0jgCKNE55pXjBDOMkaJ1bsXsoNUsQkYSbzY2ANmiwioStx9fYgR xGYW0JRoOvEZLC4sYCixqnsxVI2RxLEZc6FsJ4ndc/aB1bMIqEjs2NHDAmLzCvhKTNw+nxli WRerxNZP08AaOAVMJR6d/AlmMwKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zzBC2qMTLx/9YIWwl iY+/57ND1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI0dp cWpZbrqR4SZGYKQck2Bz3MG44JPlIUYBDkYlHt4Ni1tChFgTy4orcw8xSnOwKInzalbPCxYS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaH5I8MdCznxm8/WfPT+Ke974YmI9+excr9+7l+05 K7pMYXp0GmPK6xSxP31buDtXik9OetFSl/+oXCKVa1mHLf+Oc02uO5wWf1nf/5a1/YNHxDKe fbNTVTe3vCzbsUI+qlVm7WOR4qqkC7PM2DaYGgT2aB+s3PGVSeJ1BpdgZpLhUQemdKFrSizF GYmGWsxFxYkAFvtoGnUCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2RlRs_WCRrnzNZfk1guxYYKBCt8
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Dec 2014 05:46:10 -0000

Hi Marc,
missed to add note on my intention of use of BFD Echo.
I think of it as on-demand mechanism only, not proactive. Thus it would most likely be invoked to investigate BFD sessions that already failed or unstable.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger
Sent: Monday, December 08, 2014 1:21 PM
To: Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

Hello Manav,

> For the echo mechanism to work, do you agree that you would have to 
> continuously send Echos so that you can detect the issue?

that's what I had in mind, yes


> Or are you suggesting that once BFD flaps we will start sending Echoes 
> overloaded with debug information to detect the issue?

interesting idea - that would be an alternative use, collecting forensic data. Maybe we should support that too!


My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it is 
not a real problem, any echo stamping/updating in the forwarding path would 
require an hardware update (or reprogramming, if your hardware allows) and in 
this case one could boldly state that the echo packet must leave via the 
ingress port :-)


Regards, Marc





On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote:
> Hi Marc,
> 
>> 
>> 
>> * Greg's echo idea is of course do-able - when you think timestamping in
>> hardware can be done then it can be done in the forwarding path for echos 
>> as
>> well. Depends on your hardware :-) and on an agreed (minimal) format for
>> echo. As mentioned BFD echo is not defined/used for multiple BFD features,
>> which limits it's use though.
>> 
> 
> For the echo mechanism to work, do you agree that you would have to 
> continuously send Echos so that you can detect the issue?
> 
> Or are you suggesting that once BFD flaps we will start sending Echoes 
> overloaded with debug information to detect the issue?
> 
> I'd like to understand this before the mailing list sees a barrage of 
> emails. Alternatively, we can also take it offline and only report the 
> summary of our discussion to the list.
> 
> Cheers, Manav