Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 27 July 2020 19:14 UTC

Return-Path: <mjethanandani@gmail.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 22CAC3A0B24 for <rtg-bfd@ietfa.amsl.com>; Mon, 27 Jul 2020 12:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nJayDMCYO1dj for <rtg-bfd@ietfa.amsl.com>; Mon, 27 Jul 2020 12:14:14 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FA03A0B21 for <rtg-bfd@ietf.org>; Mon, 27 Jul 2020 12:14:14 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id k13so823138plk.13 for <rtg-bfd@ietf.org>; Mon, 27 Jul 2020 12:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/mM5t16/6ooxum8KD97sEPLOledoCue+Pb9mDMnfChI=; b=Bzk0Gi5srfPVJydeEIk0YRHbDSTeCdqjYuGI65HA7Uxww//R/a7F8ivcmN8UCBMsZh YrCfDRAoDSzuMNw2nYzpWwYtmrjRxDHdlEMgnCJGnhQlKi7YSHBQNLLdILPRMmYtff9T FQNgQpRaV5CY6gvEf1sS2820pz7yn/RnSKr6vHO4wT3yPb60DTC8BJ1wynuiznao9UGG OaR41coADCJnuWvmNnZxU2ZCAfE748za+b4G7HT8zXTYehCLCL2qhp0MHp2p5Dz8urbu MzJl7vaFHIYuqcRl++zJ8ZfwNHthO9b6gfiG/ERWpq0fJoyYpH6udbyfu+EwKPHWCGKd FJOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/mM5t16/6ooxum8KD97sEPLOledoCue+Pb9mDMnfChI=; b=LCDiLt/Og58ZyoixYvagoWqIge4wexeo7+QAF36ekegnondkeZW5B/nstfMm9y26m3 dqv67qnls2Nx04xLj+dRRmCg9RG0JQnkFtT3IG2FeK0XOaBfo07bp6iTKxk/YmCige13 +v5lNlOgthOvcsOQGVHtmU0ayDPkWHVi60EpLWgv/1i3sXrq5iErEBbw3QNzRjrSpQia SZrB54bqTh/IYPt9UipFTaBaWQEQtYzNBeVVUTUvjvgwK16MBpGKJDB7OibvE6d6kQdJ 9fih8dFBzdrn9lVqidMEl5h6iDEKX8zhpIbYJIXFLbrAtrbz5lGhcjKklCj89zRO1Pac NJUg==
X-Gm-Message-State: AOAM531G6NvtVwyAADibrdKOKuVuVzDedtfx2iwMbhCPBMKp4w/F4byD xEBz2hs7ETesdRLofrMW2pULmSNR
X-Google-Smtp-Source: ABdhPJx19/oBWv0kryCrT7Tz3oF/ooM8dUeKRBZWuTDgj8eAnp9FexOtKNd6amITSzTkyKjawoVELA==
X-Received: by 2002:a17:90a:ce0c:: with SMTP id f12mr733239pju.19.1595877253591; Mon, 27 Jul 2020 12:14:13 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:832:30a0:8e73:f872? ([2601:647:5600:5020:832:30a0:8e73:f872]) by smtp.gmail.com with ESMTPSA id f29sm15554059pga.59.2020.07.27.12.14.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 12:14:12 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
Subject: Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <012789B0-D1D4-47F4-9593-4E9963931228@cisco.com>
Date: Mon, 27 Jul 2020 12:14:11 -0700
Cc: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B34D35B-4659-4C8E-AF4E-A55D632C3D18@gmail.com>
References: <159466724499.14803.15233027731222579839@ietfa.amsl.com> <FC5206AF-9CDB-4CC2-9967-B4BF5A17141B@gmail.com> <012789B0-D1D4-47F4-9593-4E9963931228@cisco.com>
To: Reshad Rehman <rrahman@cisco.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/3dStvFym_KQI0if5CyT-HcQhQRk>
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: Mon, 27 Jul 2020 19:14:16 -0000

Hi Reshad,

Thanks for combing through the changes.

> On Jul 22, 2020, at 4:10 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
> 
> Mahesh, thanks for addressing my comments. 
> 
> I will update the shepherd write-up based on my comments below.
> 
> General: both "BFD control packet" and "BFD packet" are used. I think we should stick to "BFD control packet".
> General: s/BFD Control packet/BFD control packet/

Done.

> 
> Introduction, next-to last paragraph. Instead of "The interval of this non-state change frame can be...", I'd suggest "The interval of these BFD packets can be..." or "The interval of the BFD packets without a significant change can be...". Anyway remove "frame" as previously discussed and avoid use of "non-state change" now that you've defined what a significant change is.

Done.

> 
> Section 1.2. The new table could be incorrectly interpreted as having 1 entry. Suggest changing this to bullet form would make it clearer.

Ok.

> 
> Section 1.2 introduces the term "configured interval" but section 2 uses the term "configured period". Also for the description, what about "interval at which BFD control packets are authenticated in the UP state". 
> Also wondering if instead we should have a new bfd.AuthUpStateInterval state variable (see 6.8.1 of RFC5880) since having this value may not always be configured (implementation specific)?

Changed all “configured period” to “configured interval” and updated the description.

> 
> Section 2. Replace  "frame" by "packet" or "BFD control packet"  as appropriate.

Ok.

> 
> Section 2. Thanks for modifying the table as per our discussions. Regarding adding AdminDown to the table, I believe I misled you. Our discussion was based on "what happens if we're UP and receive a packet which says AdminDown"? As per 6.2 of RFC5880, the receiver would go to DOWN state. However the rows/columns in the table are for the local state (new and old), and not for state in received packet. Since we can't go to AdminDown state or leave AdmnDown state based on a packet received, AdminDown state should be removed from this table . I think it'd be good to add a reference to the BFD FSM (6.8.2 of RFC5880) in the paragraph before the table.

You mean Section 6.2 of RFC 5880.

> 
> Section 2. For configured period (or whatever we decide to call it) add a reference to section 1.2.
> 
> Section 4. s/to to/to/

Done.

Will post the draft with these changes shortly.

> 
> Regards,
> Reshad.
> 
> On 2020-07-13, 4:56 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <rtg-bfd-bounces@ietf.org on behalf of mjethanandani@gmail.com> wrote:
> 
>    This version of the draft addresses some of the shepherd comments. Welcome any feedback.
> 
>> On Jul 13, 2020, at 12:07 PM, internet-drafts@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF.
>> 
>>       Title           : Optimizing BFD Authentication
>>       Authors         : Mahesh Jethanandani
>>                         Ashesh Mishra
>>                         Ankur Saxena
>>                         Manav Bhatia
>> 	Filename        : draft-ietf-bfd-optimizing-authentication-10.txt
>> 	Pages           : 8
>> 	Date            : 2020-07-13
>> 
>> Abstract:
>>  This document describes an optimization to BFD Authentication as
>>  described in Section 6.7 of BFD RFC 5880.  This document updates RFC
>>  5880.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-10
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-10
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
> 
>    Mahesh Jethanandani
>    mjethanandani@gmail.com
> 
> 
> 
>