Re: BFD stability follow-up from IETF-91

Manav Bhatia <manavbhatia@gmail.com> Mon, 08 December 2014 05:42 UTC

Return-Path: <manavbhatia@gmail.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 9E3B71A6F13 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] 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 hFw42U4Hqquz for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 21:42:48 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141D31A6EFB for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 21:42:48 -0800 (PST)
Received: by mail-ob0-f177.google.com with SMTP id va2so3023441obc.8 for <rtg-bfd@ietf.org>; Sun, 07 Dec 2014 21:42:47 -0800 (PST)
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:content-type; bh=tHkeQekcwSqew3uqTWuEBwKPSyqrrNC7IBHIkvR6DxA=; b=pjWkx58pcUq9SCQHrHsuQUL01Ec+P/PWqJFMXkaPYfBRLXeNLKdNgp2oUU66T8e6t8 J3TAtsYr9ploMrv8WGhmtR4zedDpU8xKm1xU+wqR7TBV1kJgxbgkG7BaRr+Un/MYyR/j MttJywKNDKH7t+lKGn8LYXfarwJTNz0nN6K09N2UdMXgRAD4H3W0tyXcJurV3qOuORBd UMKKjSTkffQ4ykky1+GvPfDVmz5ytyNtzE+T6idHO9FSm33bdWYpucuiUFyNA/3yBzNX DYMN3BrPMitb1hlQnaPmhKzr8DFbW3qkVVRGvBe/qlHcIBcN1Wna7HWK7oyGTuOsA4Lj pHLA==
MIME-Version: 1.0
X-Received: by 10.202.80.21 with SMTP id e21mr5835235oib.65.1418017367399; Sun, 07 Dec 2014 21:42:47 -0800 (PST)
Received: by 10.76.178.199 with HTTP; Sun, 7 Dec 2014 21:42:47 -0800 (PST)
In-Reply-To: <20141207212102448099.e2e4012a@sniff.de>
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>
Date: Mon, 08 Dec 2014 11:12:47 +0530
Message-ID: <CAG1kdogRJ1PU+uaGAZkRP=QhrGv-KcY+8yAz23sobbykL2pLXQ@mail.gmail.com>
Subject: Re: BFD stability follow-up from IETF-91
From: Manav Bhatia <manavbhatia@gmail.com>
To: Marc Binderberger <marc@sniff.de>
Content-Type: multipart/alternative; boundary="001a113d8408782bc90509ade508"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Bp33i79Z30UbQwU_fYwGFAZLKvs
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:42:56 -0000

>
> Hi Marc,
>


> > 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
>

.. and i dont like this. Are you saying that for each BFD session now you
will run a parallel BFD echo session that would carry the debug data? Your
scaling just went for a toss !!


>
> > 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!
>

This would help if the flap is deterministic-ally reproducible. If its not,
then how long do you run the Echo BFD? And what happens to the original BFD
session? You run the two parallel-ly?

Cheers, Manav


>
> 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
>