RE: BFD WG adoption for draft-haas-bfd-large-packets

"Les Ginsberg (ginsberg)" <> Thu, 25 October 2018 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC325130EC6 for <>; Thu, 25 Oct 2018 15:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r1zWH5wgpgUu for <>; Thu, 25 Oct 2018 15:28:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34CA5130EBB for <>; Thu, 25 Oct 2018 15:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4230; q=dns/txt; s=iport; t=1540506534; x=1541716134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PLZ5uReavjeTbIVe2u8Y5enATmR+LqcVkCL5yJeA5vs=; b=Ndb9BoQ9qEwQdFj36qRLzsXzUgZIdU6XdekmMMwq23VaOyR76/I9N0mQ szaDVfwSn38KIgHyV+dDROCxgnJ1gTlh72CjkInWbIodx0qiDrFoBP3ou cH3OEJLtzORUG4awtMpNriITJwANrVBMeDAKRowFE92lyHvD0T9Hbso2s M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,425,1534809600"; d="scan'208";a="191718630"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 22:28:53 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9PMSrkr012728 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2018 22:28:53 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Oct 2018 17:28:52 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 25 Oct 2018 17:28:52 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Jeffrey Haas <>
CC: "Naiming Shen (naiming)" <>, "Reshad Rahman (rrahman)" <>, "" <>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Topic: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Index: AQHUZn7F2obCS5tWFUCJRL2ls+mZdKUo1C+ggAHIywD//67wkIAAV7mA///Hi8CABg0XgIAAHPRw
Date: Thu, 25 Oct 2018 22:28:52 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 22:28:57 -0000

Jeff -

Inline - hopefully more readable than before...

> -----Original Message-----
> From: Jeffrey Haas <>
> Sent: Thursday, October 25, 2018 8:38 AM
> To: Les Ginsberg (ginsberg) <>
> Cc: Naiming Shen (naiming) <>; Reshad Rahman
> (rrahman) <>;
> Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
> Les,
> I *think* the following text is yours.

[Les:] Yes - it is.

> On Mon, Oct 22, 2018 at 12:36:52AM +0000, Les Ginsberg (ginsberg) wrote:
> > [Les:] So, this has some implications:
> >
> > We have both a transmit interval and a multiplier for a BFD session because
> we allow that some BFD packets may be dropped for reasons which do not
> represent a true loss of connectivity. Therefore up to N-1 consecutive
> packets may be dropped w/o triggering a session state change. If large BFD
> packets are “occasionally” inserted this means there are intervals during
> which N-2 packets drops (not counting the BFD large packet) would be
> sufficient to trigger a BFD session state change. Further, if the processing of
> the large BFD packets makes it more likely that subsequent BFD packets will
> be dropped (e.g., because the processing of the large BFD packet simply
> takes longer) then it is possible that a BFD session state change might be
> triggered simply as a side effect of the insertion of the large packet into the
> data stream.
> >
> > You also are now defining a “child session” which is embedded within the
> parent session. BFD large packets are then not meant to influence the parent
> BFD session state and therefore have to be processed separately. This – in
> many ways – is equivalent to defining “another protocol”. I’ll grant it might be
> a bit simpler as it can inherit some things from the parent session – but it
> certainly is no longer simply a transparent part of existing BFD session
> operation.
> The draft I had previously worked on with Xiao Min discussing probing using
> BFD Echo had the concept of probes that would happen wherein the session
> is not torn down.  The example carries similarly with the "send occasional".
> I suggest taking a look at a different draft that might help direct this portion
> of the discussion:

[Les:] I have read this draft - not sure how relevant it is.

Naiming had suggested that MTU sized packets need not be sent all the time but only occasionally - 
and that a failure might not be used to take the BFD session down - 
rather it would be seen as a "soft-failure" and reported separately from the BFD session state.
My response was in that context - which it seems was also in your mind in your BFD Echo proposal.

This, however, seems not to be what Albert has in mind - as he has since commented that he really wants to have sub-second detection of MTU issues and 
he wants traffic rerouted "immediately".


> -- Jeff