IETF Logo Mail Archive

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

Jeffrey Haas <jhaas@pfrc.org> Thu, 25 October 2018 15:00 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 62C91127133 for <rtg-bfd@ietfa.amsl.com>; Thu, 25 Oct 2018 08:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mLY6RY-DkFm5 for <rtg-bfd@ietfa.amsl.com>; Thu, 25 Oct 2018 08:00:37 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 02183130E6A for <rtg-bfd@ietf.org>; Thu, 25 Oct 2018 08:00:36 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 814DD1E44B; Thu, 25 Oct 2018 10:59:59 -0400 (EDT)
Date: Thu, 25 Oct 2018 10:59:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Message-ID: <20181025145958.GA12336@pfrc.org>
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> <8ED9D25B-C21A-4A77-95CB-237F1142AFB4@gmail.com> <2868B780-B496-48A2-A45A-8C8BFB74CBF5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2868B780-B496-48A2-A45A-8C8BFB74CBF5@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/sAd3bnJUhImeF6BsDToc_UVQddY>
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 15:00:38 -0000

Naiming,

A specific comment on the crypto overhead:

On Mon, Oct 22, 2018 at 07:38:18PM +0000, Naiming Shen (naiming) wrote:
> 
> Probably just bandwidth increase, and if you need encryption/decryption on the packets,
> then large packets will cost more in CPU.

The BFD protocol has you check the contents over the BFD PDU.  In the case
of an expanded IP payload, this procedure wasn't expected to be modified.
Thus, the crypto load should not increase. 

Covering some of the other comments, the pps of the BFD session need not
increase, alhtough the bps increases.  Scaling is thus a matter of how the
implementation handles scaled bps vs. pps for its BFD implementation.

-- Jeff

v2.23.0 | Report a Bug | By Email