Re: I-D Action: draft-ietf-bfd-yang-06.txt

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 01 August 2017 00:17 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 87BAB12EC32; Mon, 31 Jul 2017 17:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sxkuXBKW1GvN; Mon, 31 Jul 2017 17:17:11 -0700 (PDT)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 EC63612EB99; Mon, 31 Jul 2017 17:17:10 -0700 (PDT)
Received: by mail-pf0-x242.google.com with SMTP id t86so173754pfe.1; Mon, 31 Jul 2017 17:17:10 -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:message-id:references :to; bh=OtEblL1GepQl+x4mZ3UGRx9DTrGwxh1WsJGzRg7jPNE=; b=oM2QS4qomYTB4hVRdKH6nUA0RgvoVh23rA8hndzgr2c68krICLokwP4Oe5q611/yPf Nk+H48B5d8okEVR4O4kFMF4nRYX3RqeN+g4diO4svbMNfEO2LViRXmCQm2dvTpzYBNJb R5wZJd5yMllIFlJWg6UwC2N00AOWqrsN/OA/p1q3bAiypbdA6bQSHOQdi9/ACFunpu/x 7S55fgha8z6EqdIqVL8UE1EpPzthhC/HDYz9B+KmSN4Xhey+ElzFkon491YrJpWk1dpu d4olX9e4nUIp0mu/fdnfC1hE7Ueqe5Xcor3fOQQ+pCQ7Ps5RJKCWypXEwlrlC9O9FKWn SzIg==
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 :message-id:references:to; bh=OtEblL1GepQl+x4mZ3UGRx9DTrGwxh1WsJGzRg7jPNE=; b=Kh7D1bJ3Zmw+PRcv7lpremg7gUJODFiF6ChPnIukt/iTky7ADR2Yk9fKSBC5e5lqyz 4t9/kJF1IizIK0thhjIa17hhFSEUzAx2HGjTAh12ssH1rHsOYSU/hBhyjeewGwVW+rHU JXEWg3i4L7ajUCkmv+E1MaZQguqPWA/1rq8EwJsfturcNenY+J7rdw/DOjoT3IRbZfnP 6m7CGrQldkj6QF4q3zNgc/BOEtP9VsaJCOGiRZRK/LWN7X8YfU1U/lkShcWttwXNA1p0 Hev+84+jbNbgaz4kP/mlagGLLwnweapCOahpsy4aRCjq9NZFBSlNeotEYP3Wc5uPhW60 e4gQ==
X-Gm-Message-State: AIVw113cZCShhOA2xPAosBiiB5mwnnmT7YeBhOj4vzPu1VS4D8NXmUJw F5O7Sx1GSGAvTQ==
X-Received: by 10.98.91.71 with SMTP id p68mr17400768pfb.209.1501546630487; Mon, 31 Jul 2017 17:17:10 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1254:d0c:e1af:5a13:d5a5? ([2001:420:30d:1254:d0c:e1af:5a13:d5a5]) by smtp.gmail.com with ESMTPSA id a87sm5997075pfg.18.2017.07.31.17.17.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Jul 2017 17:17:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_42E005B0-01A5-4BBB-9D55-92DBCE085788"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org>
Date: Mon, 31 Jul 2017 17:17:34 -0700
Cc: Yingzhen Qu <yingzhen.qu@huawei.com>, "Acee Lindem (acee)" <acee@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, Reshad Rahman <rrahman@cisco.com>
Message-Id: <D26CB257-E4B2-42FA-940E-BF77C8BC1751@gmail.com>
References: <D59FB38C.2CE83D%rrahman@cisco.com> <D59FB594.BA3A0%acee@cisco.com> <D59FB7D2.2CE8F1%rrahman@cisco.com> <D59FB934.BA3C3%acee@cisco.com> <D59FBE2A.2CEA06%rrahman@cisco.com> <D5A01A7B.BA49E%acee@cisco.com> <C71CC69E-DAE4-49E0-983A-9B2EE9B4CD46@gmail.com> <D5A12762.2D4DB5%rrahman@cisco.com> <E4E310A2-A79C-403E-B68E-A39B76E2C5E0@gmail.com> <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <BAF4C9E6-ED02-4E25-89DD-2FA181AF3B72@gmail.com> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/SJHvHMdfVOSTAX_xkhEuY9MFl_M>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 01 Aug 2017 00:17:13 -0000

> On Jul 31, 2017, at 1:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> Mahesh,
> 
>> On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> 
>> Jeff,
>> 
>>> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>>> 
>>> On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote:
>>>> The changes are done and pushed to GitHub. Use the grouping client-cfg-parms.
>>> 
>>> Question: For implementations that use Echo mode, is that something the
>>> protocol client configuration impacts or is it chosen by the system
>>> automatically?
>> 
>> I am not sure I understand. 
>> 
>> For Echo mode, there is a separate grouping called echo-cfg-parms that allows clients to specify the desired-min-echo-tx-interval and required-min-echo-rx-interval. 
>> 
>> That is somehow different from desired-min-tx-interval and required-min-rx-interval that one can specify for a normal BFD session. For the life of me, I do not understand why the two need to be different :-(. I must be getting amnesia. Maybe one of the co-authors will jog my memory.
> 
> The protocol permits those values to be distinct from the async ones.  They should be in a separate set of params.

Agree. 

> 
> My point, unless my very quick glance at the module mislead me, is that you can't configure to use echo mode - if it's supported - in the grouping imported by the IGPs.

In the current model, it is modeled as a separate grouping with its own set of parameters. The expectation is that implementations that want to define echo mode would use the grouping. Defining the parameters also implicitly defines that echo-mode is enabled. Are you saying that using the echo grouping is not enough? 

But I do think that the parameters needs to be further protected by an if-feature statement that says

  grouping echo-cfg-parms {
    if-feature echo-mode;
    description 
      "BFD grouping for echo config parameters”;

> 
> My implementation doesn't support echo, so I don't have any opinion about where configuration of those belongs or not.

With the feature statement, these echo parameters can exist inside of client-cfg-parms, instead as a separate grouping and will be included by the platform only if the feature is defined. And this would be my preference. Is that what folks would also prefer?

> 
> -- Jeff
> 
> 
> 
>> 
>> Cheers.
>> 
>>> 
>>> -- jeff
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
Mahesh Jethanandani
mjethanandani@gmail.com