Re: BFD stability follow-up from IETF-91

Manav Bhatia <manavbhatia@gmail.com> Wed, 26 November 2014 06:56 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 919651A1A34 for <rtg-bfd@ietfa.amsl.com>; Tue, 25 Nov 2014 22:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 R8PU17zsdkKh for <rtg-bfd@ietfa.amsl.com>; Tue, 25 Nov 2014 22:56:42 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881A71A1B93 for <rtg-bfd@ietf.org>; Tue, 25 Nov 2014 22:56:42 -0800 (PST)
Received: by mail-oi0-f49.google.com with SMTP id i138so1592595oig.22 for <rtg-bfd@ietf.org>; Tue, 25 Nov 2014 22:56:41 -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=dbnMIks8G96Zga4aTvAVwPOEVAzgEhRpG2ZMg0HCaQw=; b=sJn/oic1Px+NqZvi7MnkN5fkMZ3RdnTMeVQ+gYXpixl3gH53velylg6R36lR6EfqqG giPaL78By4cM2jxTUbCPoSFohOIGhV/bzVPAj1UG4Mx2kVY2g70UIMaQO3JqrPXGKAYC 9SIk6arjvAnH+AwSfsbP7RDNHJa+reLsmRKt1PCGZonvwRFeAdW5DzM3Zr3TeJDJ2CQu Nnorl40hSikKZ6j7NF8TN5ydOoaXvnOhWHlrHyzoeN+/w6XST+tOvKoUcTTqsW7BJHnt wdHN0Dpx2psKi1xe2v3/O5tg4glS6aav1sFbC8q72CFfhd3M4f6JtJHzrXwv1j+V7SJJ UqwA==
MIME-Version: 1.0
X-Received: by 10.202.80.21 with SMTP id e21mr17544267oib.65.1416985001716; Tue, 25 Nov 2014 22:56:41 -0800 (PST)
Received: by 10.76.178.199 with HTTP; Tue, 25 Nov 2014 22:56:41 -0800 (PST)
In-Reply-To: <20141126001931.GJ20330@pfrc>
References: <20141126001931.GJ20330@pfrc>
Date: Wed, 26 Nov 2014 12:26:41 +0530
Message-ID: <CAG1kdoghcA=xSaXmkr68qduH2t8oC=-ZazoQztj8JK12SazKsw@mail.gmail.com>
Subject: Re: BFD stability follow-up from IETF-91
From: Manav Bhatia <manavbhatia@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NpsdreLPbY0jIZ8FivbB0GUqAOk
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: Wed, 26 Nov 2014 06:56:44 -0000

Hi Jeff,

I vividly remember the original intent of the stability draft was to
help debug BFD failures -- to isolate the issue at the RX or the TX
side Time stamping would have helped in debugging whether the BFD
packet was sent late, or whether the packet was sent on time and also
arrived on time but was delayed when passing it up the BFD
stack/processor (lay in the RX buffer for tad too long), etc. But then
time stamping came with its own set of issues, and was hence dropped
from the original draft.

Can the authors send a summary on the list on why time stamping was
dropped so that we're all clear on that one.

The current proposal does help but is not complete.

Assume that the RX end loses a BFD session and learns later that it
did eventually receive the missing BFD packets (based on the seq #).
How would it know which end was misbehaving? Was it a delay at the TX
side, or was it the RX that delayed passing the packets to the BFD
process(or). This is usually what we want to debug and i want to
understand how this draft with sequence numbers can unequivocally tell
me that.

I believe the work is important and addresses something thats really
required (spent too much time debugging why BFD flapped!). Clearly
what would help is putting a small section that describes how we can
use the sequence numbers to debug what and where things went wrong.

Cheers, Manav


On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in
> Honolulu.  The slides can be viewed here:
>
> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx
>
> To attempt to simplify the presentation, the contentious portion of the
> timers were removed from the proposal, leaving only the sequence numbering
> for detecting loss of BFD async packets.
>
> When the room was polled to see whether the draft should be adopted as a WG
> item, the sense of the room was very quiet.  As promised, this is to inquire
> for support for this draft on the WG mailing list to make sure the whole
> group has a voice.
>
> It should be noted that post-meeting discussion on the fate of this draft
> noted that BFD authentication code points are plentiful and are available
> with expert review.  Should the draft authors wish to continue this work as
> Experimental, that is an option.
>
> -- Jeff
>