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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 14 August 2017 15:24 UTC

Return-Path: <rrahman@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 ACD11132386; Mon, 14 Aug 2017 08:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 sWPSTM9cAEI4; Mon, 14 Aug 2017 08:24:16 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A04132376; Mon, 14 Aug 2017 08:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2264; q=dns/txt; s=iport; t=1502724256; x=1503933856; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3k4qd7+8UGbMrUPATqUxs5A7DzCj3U3ga2fTJ9Tx6/E=; b=djTuQIdrC5js71Ltzo8clY5Z2vwEnKMwI1JGK6ajjNDOTJCXcZ4tKUzp dpnA2PDFbiYniXQ/4Whl4g+lFGK0LyodiBEEDqcPOuD3d2dI+6OUCu5et EJV5ofdu6hhvqyZhkYmCUv4HPvV7e8/CV6O5+DTxgrctYMpPDJK9Z8G13 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAABuwJFZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeAeOCpAPgW6WGIIShUcChHk/GAECAQEBAQEBAWsohRkBBXk?= =?us-ascii?q?QAgEIDgouMiUCBAENBYovrxmLYAEBAQEBAQEBAQEBAQEBAQEBAQEfgyiCAoFMg?= =?us-ascii?q?WODJ4pnAQSgMQKUOpJVlhQBHziBCncVhWAcgWd2iT4BgQ4BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,373,1498521600"; d="scan'208";a="471410777"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2017 15:24:07 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7EFO7KC008150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Aug 2017 15:24:07 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Aug 2017 10:24:06 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Mon, 14 Aug 2017 10:24:06 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Mahesh Jethanandani <mjethanandani@gmail.com>
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>
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt
Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt
Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAY+3gP//wcOAAAht2QAAApY1AACKkk0AAAcEyAAAAQL8AAAHDDsAAB4sBYAAAdJCAAACGL0AAoMA9QA=
Date: Mon, 14 Aug 2017 15:24:06 +0000
Message-ID: <D5B73133.2D861A%rrahman@cisco.com>
References: <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> <D26CB257-E4B2-42FA-940E-BF77C8BC1751@gmail.com> <20170801144129.GC24942@pfrc.org> <F319C69C-3A4E-4C5C-ADA4-37BDFD97E91A@gmail.com> <20170801163340.GD24942@pfrc.org>
In-Reply-To: <20170801163340.GD24942@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.64]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <A5F575829994594AAE91A0B8BCC09407@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/gs0B1Q2UEXGBUXeJCovYbHNGZAA>
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: Mon, 14 Aug 2017 15:24:19 -0000

I am gradually catching up to emails so I may not have absorbed all the
emails I have gone through yetÅ .

Regarding echo config, we agreed in Chicago to remove the echo config
based on the fact that implementations of echo are vendor specific. e.g.
An implementation which has echo as continuous would likely have echo
configuration whereas an implementation which has echo as on-demand may
use RPC. There is an example of a vendor augmentation for echo config in
Appendix A.1.

Regards,
Reshad.



On 2017-08-01, 12:33 PM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

>On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote:
>> > I'm ambivalent.  This depends really on real world behavior.
>> > 
>> > As we saw from some brief googling yesterday on Cisco IOS/IOS-XR
>>docs, that
>> > implementation doesn't appear to expose echo intervals as a separably
>> > configurable item.  It did, however, expose a boolean to disable echo.
>> 
>> True. But the standard seems to imply the ability to configure echo
>>values separately. Worst case implementations would have to set both the
>>values to be the same.
>
>The protocol does. But that doesn't mean the config model should.
>
>> > This minimally suggests that there should be a "use echo mode" flag.
>> 
>> Will add a boolean to enable/disable echo mode.
>
>I think that's a good start.
>
>> > The remaining homework is to figure out whether we should expose
>> > configuration state for echo directly in this version of the yang.
>> 
>> Per NMDA guidelines, unless the configuration state values are
>>different from config, we do not need to model them as separate
>>attributes.
>
>Right.  So, again need to check real world implementations.
>
>If it's the case that implementations supporting echo only use a single
>set
>of the intervals for echo or not, then we only need that in the model.
>
>If it becomes the case that an implementation supports echo intervals
>differently, a vendor *could* augment the model to support such values.
>However, since this is imported via grouping, it means that the
>augmentation
>has to be done in each module that uses the grouping.
>
>I hate yang grouping augmentation rules. :-P
>
>-- Jeff