IETF Logo Mail Archive

Re: BFD stability follow-up from IETF-91

Manav Bhatia <manavbhatia@gmail.com> Thu, 04 December 2014 15:22 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 7E3521AD41B for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 07:22:24 -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 zzljETuYh640 for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 07:22:18 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD1A1AD419 for <rtg-bfd@ietf.org>; Thu, 4 Dec 2014 07:22:18 -0800 (PST)
Received: by mail-oi0-f50.google.com with SMTP id a141so12548040oig.9 for <rtg-bfd@ietf.org>; Thu, 04 Dec 2014 07:22:17 -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=j68hdx1dy+1FS22zrcBEfPeDor+1KQbYWUQMrnO1hKY=; b=lvSjhFcMInUBAo9MMNiraczs6ePrXPVgjHBDAQjay3DYuULfUei9EveWyD2vjjkCoc 0nruoj2il/eBvL3SZ9T+EPQVFcyDbVtxgN9OiUq50ui32uKzdrfNGq/uEg6Zp6BDHgtM ABsGBB+ZVVuB/ZTfybq96EC6XqrQPIbUJtUaCUx9ODZnidDnz28KlzRsZ9259msWDPz8 gLduPg0NkMC07mZ5ggwOou/hz7ZXMPCbSqC7KwGmvScwnSSHPJcgZw6tzCd4AJ9t0Jhr TDutc9Vn78iUM8jl02lfGZp+EszXYx8jPyE1RtiZspX5NSBzNu7Ibmkn2MBWd0n2b7vP QTKA==
MIME-Version: 1.0
X-Received: by 10.202.69.137 with SMTP id s131mr1758434oia.103.1417706537702; Thu, 04 Dec 2014 07:22:17 -0800 (PST)
Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 07:22:17 -0800 (PST)
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3943F5AE4AE@xmb-aln-x01.cisco.com>
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>
Date: Thu, 04 Dec 2014 20:52:17 +0530
Message-ID: <CAG1kdoh5DwdKrJWK_aSvo4KQ6Xu5ZaTObe_PLhV66YZ4yQozmg@mail.gmail.com>
Subject: Re: BFD stability follow-up from IETF-91
From: Manav Bhatia <manavbhatia@gmail.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Content-Type: multipart/alternative; boundary="001a113dae32935ddc05096586f3"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-aCvT0_cJtKAdwrZHY7CqjvaFbM
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: Thu, 04 Dec 2014 15:22:24 -0000

Hi Nobo,

The echo proposal doesnt make any sense. I thought the one with carrying
some info as part of the the UDP or the IP payload made some.

Having spent countless number of hours debugging a "BFD flap" i would
definitely like to have a std-track mechanism that aids me in debugging the
root cause.

Cheers, Manav

On Thu, Dec 4, 2014 at 8:44 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:

>  [no hat on, btw]
>
>
>
> Hi Manav,
>
>
>
> If what you say is the only requirement not met, one approach may be to
> pursue a non-standard-track document describing some suggested
> implementation techniques to locally store TX/RX timestamp.
>
>
>
> Given that echo approach will be less accurate and given that we seem to
> be having difficulty converging, I thought I’ll throw out another idea.
>
>
>
> Thanks!
>
>
>
> -Nobo
>
>
>
> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com]
> *Sent:* Thursday, December 04, 2014 9:53 AM
> *To:* Nobo Akiya (nobo)
> *Cc:* Santosh P K; MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan
> (venggovi); Gregory Mirsky; Marc Binderberger; rtg-bfd@ietf.org
> *Subject:* Re: BFD stability follow-up from IETF-91
>
>
>
> Nobo - Locally storing TX/RX timestamps is not interoperable.
>
>
>
> Cheers, Manav
>
>
>
> On Thu, Dec 4, 2014 at 7:30 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
>
> A quick question to understand where we are.
>
>
>
> If we had:
>
>
>
> 1.      Standardization of Null Authentication (i.e., sequence numbers)
>
> 2.      Implementation of local TX/RX timestamp mechanism described by
> Marc below
>
>
>
> What are the core requirements which have not been satisfied?
>
>
>
> Thanks!
>
>
>
> -Nobo
>
>
>
> P.S. No, there is no need to standardize BFD echo contents.
>
>
>
>
>
>

v2.23.0 | Report a Bug | By Email