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

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

Return-Path: <ginsberg@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC325130EC6 for <rtg-bfd@ietfa.amsl.com>; Thu, 25 Oct 2018 15:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 r1zWH5wgpgUu for <rtg-bfd@ietfa.amsl.com>; Thu, 25 Oct 2018 15:28:54 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CA5130EBB for <rtg-bfd@ietf.org>; Thu, 25 Oct 2018 15:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0AEAAAcQ9Jb/5RdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfygKg2uIGIwYgg2DQJNcgXoLAQEjhEkCF4J6ITQNDQEDAQECAQECbRwMhToBAQEBAgEjETMSDAQCAQgOAwQBAQECAiYCAgIwFQgIAgQOBQiDGoF5CA+oLoEuhDAChWAFgQuKWxeBQT+EI4MbAQEDhGGCVwKedgkChmaKDSCBUogRhmCMaol4AhEUgSYdOIFVcBWDJ4sZhT5vjAmBHwEB
X-IronPort-AV: E=Sophos;i="5.54,425,1534809600"; d="scan'208";a="191718630"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 22:28:53 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (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 xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Oct 2018 17:28:52 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Thu, 25 Oct 2018 17:28:52 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: "Naiming Shen (naiming)" <naiming@cisco.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
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: <a367a9ceec9e4f96ac41223a4fde494f@XCH-ALN-001.cisco.com>
References: <E052CA19-228D-4271-BF9E-7499255E7C53@cisco.com> <7332e35048d34d44a65ea70df409699c@XCH-ALN-001.cisco.com> <90B9205E-CBD8-4779-96D1-2D15BD1F7E24@cisco.com> <e08744fc4b264fd1bf9844dd0f29557e@XCH-ALN-001.cisco.com> <59DD4DA1-6C83-4D3D-92E7-B4271EB259E8@cisco.com> <2dc00a0d58db41958ad61d73d08ead17@XCH-ALN-001.cisco.com> <20181025153804.GD12336@pfrc.org>
In-Reply-To: <20181025153804.GD12336@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.162.92]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/EO7S7RQJcQMDKTjq8rfNeYYqHw4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Oct 2018 22:28:57 -0000

Jeff -

Inline - hopefully more readable than before...

> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Thursday, October 25, 2018 8:38 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Naiming Shen (naiming) <naiming@cisco.com>; Reshad Rahman
> (rrahman) <rrahman@cisco.com>; rtg-bfd@ietf.org
> 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:
> 
> https://tools.ietf.org/html/draft-ietf-bfd-stability-02

[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".

   Les



> 
> 
> 
> -- Jeff