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

"Acee Lindem (acee)" <> Thu, 27 July 2017 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2A07131C31; Thu, 27 Jul 2017 12:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z2JvXFx7tKv0; Thu, 27 Jul 2017 12:30:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D984129562; Thu, 27 Jul 2017 12:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7846; q=dns/txt; s=iport; t=1501183803; x=1502393403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E+t/rheK4G9qZXIitf7bd0IBZfU46eOiHBPCitLfBpM=; b=Kc/3kLVv9+E0enWlT61HkezDoGx34EerZgXK+kok596WDtgcAyID+t9a Hw66Qg6wHjgH976qNuM6p6q3w3H5FRlUEdQ3YQukHhn5StEiqPcoSHEh8 UH/vqM6o1zQfuoJ5AeH8NW6FGUDDfPpTzdXBaYZ0zXwjl6Gl7g/neAL/e k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAC6PnpZ/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0Fii8Qr3CCJos/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELgh2IUoMmgRoBEgEfF4J8gmEFn2YCh02MVoI?= =?us-ascii?q?MV4R7il6VcQEfOH8LdxUfh0IBdodCDRcHgQWBDgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="265039222"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:30:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v6RJU12J021523 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:30:02 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 15:30:01 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 15:30:00 -0400
From: "Acee Lindem (acee)" <>
To: "Reshad Rahman (rrahman)" <>, Yingzhen Qu <>, Jeffrey Haas <>, "" <>
CC: "" <>, "" <>
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//8hkA
Date: Thu, 27 Jul 2017 19:30:00 +0000
Message-ID: <>
References: <> <> <> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jul 2017 19:30:06 -0000

Hi Reshad, 

On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" <> wrote:

>Hi Acee,
>When we met we agreed to have a new model for clients. Afterwards I
>decided to create a new types module, and still went ahead with the
>clients module. I am fine with having everything in the types module (no
>client module).

Although I don’t feel that strongly - I just don’t see that putting the
client config params in wrappers provides any benefit. As for detriments,
it requires more one more local modules for validation and one more level
of indirection to see what we are really allowing to be configured.

>I am not sure I fully understand your comment/question on
>bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The reason we have
>2 groupings is that some protocols may decide to have just the enable leaf
>and others may also want the multiplier/timer.

The bfd-client-ext-cfg-parms grouping should use
bfd-types:bfd-grouping-common-cfg-parms rather than
bfd-types:bfd-client-base-cfg-parms - no? This would be more obvious w/o
the client module. 


>On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" <> wrote:
>>Hi Reshad, 
>>Why do we need a new YANG model for clients? Why can’t they just use
>>ietf-bfd-types.yang? I’d like to avoid the unnecessary levels of
>>indirection. In fact, it looks wrong to me since the grouping
>>bfd-client-ext-cfg-parms uses the grouping bfd-grouping-base-cfg-parms
>>which only contains the enabled leaf. I believe you meant to use
>>bfd-grouping-common-cfg-parms in the other new model. However, I don’t
>>any reason why client shouldn’t use this directly.
>>On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" <> wrote:
>>>Hi Yingzhen,
>>>The grouping is available @
>>>If you¹d like changes to the grouping, send me an email.
>>>On 2017-07-21, 12:22 PM, "Yingzhen Qu" <> wrote:
>>>>Hi Reshad,
>>>>Thanks for the summary.
>>>>Both ospf and isis models will make corresponding changes when the new
>>>>BFD grouping is available.
>>>>-----Original Message-----
>>>>From: Reshad Rahman (rrahman) []
>>>>Sent: Thursday, July 20, 2017 7:19 AM
>>>>To: Jeffrey Haas <>rg>;
>>>>Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt
>>>>We (BFD and OSPF YANG authors) had a discussion yesterday.
>>>>The agreement is that since IGP peers are auto-discovered, we want to
>>>>back the basic BFD config (multiplier + intervals) in IGP via a
>>>>BFD will provide that grouping in a specific YANG module. IGP BFD YANG
>>>>will be in a separate module (separate from the main IGP module).
>>>>On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas"
>>>>< on behalf of> wrote:
>>>>>Thanks authors for the edits on the BFD yang module.  This gets us a
>>>>>significant step closer to alignment with the rest of IETF for network
>>>>>I'd like to encourage the working group to provide feedback on this
>>>>>issue and also the changes in the module.
>>>>>As noted in another thread, we still have to figure out how to deal
>>>>>with accommodating interaction of the BFD yang module with client
>>>>>example, the IGPs.  In particular, how do you configure the properties
>>>>>of the BFD sessions that may be dynamically instantiated based on
>>>>>control protocol activity?
>>>>>-- Jeff
>>>>>On Fri, Jun 30, 2017 at 12:55:59PM -0700,
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>> This draft is a work item of the Bidirectional Forwarding Detection
>>>>>>of the IETF.
>>>>>>         Title           : YANG Data Model for Bidirectional
>>>>>>Detection (BFD)
>>>>>>         Authors         : Reshad Rahman
>>>>>>                           Lianshu Zheng
>>>>>>                           Mahesh Jethanandani
>>>>>>                           Santosh Pallagatti
>>>>>>                           Greg Mirsky
>>>>>> 	Filename        : draft-ietf-bfd-yang-06.txt
>>>>>> 	Pages           : 59
>>>>>> 	Date            : 2017-06-30
>>>>>> Abstract:
>>>>>>    This document defines a YANG data model that can be used to
>>>>>>    and manage Bidirectional Forwarding Detection (BFD).
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> There are also htmlized versions available at:
>>>>>> A diff from the previous version is available at:
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>submission  until the htmlized version and diff are available at
>>>>>> Internet-Drafts are also available by anonymous FTP at: