RE: BFD stability follow-up from IETF-91

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 08 December 2014 05:41 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 8AC461A6F0B for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:41:31 -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 t5WWcRMtjpgT for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:41:29 -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 78F311A6EFB for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 21:41:29 -0800 (PST)
X-AuditID: c6180641-f79916d00000623a-50-5484dd97673e
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.0B.25146.79DD4845; Mon, 8 Dec 2014 00:07:03 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:41:27 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Marc Binderberger <marc@sniff.de>, Manav Bhatia <manavbhatia@gmail.com>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAVyAD//64rAA==
Date: Mon, 08 Dec 2014 05:41:27 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE6CF@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+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPuO70uy0hBuuPSVhcntTGbjH7yn9m i89/tjE6MHvsnHWX3WPJkp9MHq2ru1kCmKO4bFJSczLLUov07RK4Mna+WMNecFS4Yt2sDWwN jIf4uxg5OSQETCQu9d1ihbDFJC7cW8/WxcjFISRwhFGi4+1SZghnGaPE/kUzGUGq2ASMJF5s 7GEHsUUEvCWmvnzLAmIzC2hKNJ34DBYXFjCUWNW9GKrGSOLYjLlQtpPEjjXP2EBsFgEViTfr Z4P18gr4Svw6+J8JYlkXq8TWT9PAGjgFTCUenfwJZjMCnff91BomiGXiEreezGeCOFtAYsme 88wQtqjEy8f/oN5Rkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXKUFqeW5aYbGW5iBEbPMQk2xx2MCz5ZHmIU4GBU4uHdsLglRIg1say4MvcQ ozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjB69gXcrHE9Vn5gkuTHsk5xk zY/Kfx4bZ8dmdR28qfR82TWT8o2Vt9yKXj3bu1T81YSd+qY7mP9aO1ksLi0JitKb8ba0JuBF 4XSuOQWlVcF8si9Pr7jFYRRwzOiy9NwyCzb7Z6YTZ7huufCvXYvR20Nv9ZTZl9kqpC+WBiyI OaHJbDpN44B/qxJLcUaioRZzUXEiAIiO+u9/AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Nlrc9MpSmj0em_dkZB2-5bRdw14
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:41:31 -0000

Hi Marc,
regarding your concern on ensuring that BFD Echo reply traverses the same constituent link as crossed by corresponding BFD Echo request , if it is indeed the requirement, I'll refer to revision of IEEE-802.1AX-REV in its part related to conversation-sensitive frame collection and distribution. Alternatively, we may realize the RFC 7130 needs an update that introduces or explains behavior of micro-BFD Echo over LAG.

	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