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

Yingzhen Qu <yingzhen.qu@huawei.com> Sun, 30 July 2017 17:14 UTC

Return-Path: <yingzhen.qu@huawei.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 E76AB12ECEF; Sun, 30 Jul 2017 10:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 qHsEhIDrn0Kv; Sun, 30 Jul 2017 10:14:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E711200C5; Sun, 30 Jul 2017 10:14:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSI85856; Sun, 30 Jul 2017 17:14:36 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 30 Jul 2017 18:14:35 +0100
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Sun, 30 Jul 2017 10:14:29 -0700
From: Yingzhen Qu <yingzhen.qu@huawei.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
CC: Reshad Rahman <rrahman@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, "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///B3AIAAawoAgAAI1YCAAbE+gIACaDNQ
Date: Sun, 30 Jul 2017 17:14:28 +0000
Message-ID: <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx>
References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <D596866E.2C3552%rrahman@cisco.com> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <D59904F6.2C51B4%rrahman@cisco.com> <D59FB0AD.BA38A%acee@cisco.com> <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>
In-Reply-To: <C71CC69E-DAE4-49E0-983A-9B2EE9B4CD46@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.81]
Content-Type: multipart/mixed; boundary="_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.597E13FD.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d620cfb2812958a2ecbedbaf8b4840db
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/1GdnSJtFdNvZnu2LSpfkwuzkhcA>
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: Sun, 30 Jul 2017 17:14:43 -0000

Hi all,

Please see attached ospf bfd module. Base ospf module also needs to be updated to remove the bfd enable leaf. ISIS model need to do the same change, ietf-isis-bfd.yang will look the same as ietf-ospf-bfd.yang.

Please let me know your commetns.

Thanks,
Yingzhen

-----Original Message-----
From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] 
Sent: Friday, July 28, 2017 2:25 PM
To: Acee Lindem (acee) <acee@cisco.com>
Cc: Reshad Rahman <rrahman@cisco.com>; Yingzhen Qu <yingzhen.qu@huawei.com>; Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org; draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

Would it not be better to call bfd-grouping-base-cfg-parms something like bfd-grouping-client-cfg-params or more simply client-cfg-params. We know it is a grouping and we know it is a bfd grouping. Why repeat?

> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> Hi Reshad,
> 
> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms groupings.
> Fewer similar grouping and modules will be better ;^)
> 
> Thanks,
> Acee
> 
> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
> 
>> Hi Acee,
>> 
>> What I see @
>> https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf
>> -bfd-
>> t
>> ypes.yang:
>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this grouping 
>> is defined twice, this will be fixed when I get rid of 
>> ietf-bfd-clients.yang
>> 2) bfd-grouping-base-cfg-parms has multiplier/timers.
>> 
>> Let me get rid of the client module and have everything in the types 
>> module.
>> 
>> I am not sure why you’re not seeing something different.
>> 
>> Regards,
>> Reshad.
>> 
>> 
>> 
>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:
>> 
>>> Hi Reshad,
>>> 
>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
>>> 
>>>> Hi Acee,
>>>> 
>>>> 1) I’ll see if others chime in on this but I am fine with having 
>>>> the client grouping in ietf-bfd-types.yang.
>>>> 2) bfd-grouping-common-cfg-parms has much more than just the 
>>>> multiplier/timers that the IGPs need. It also has BFD specific 
>>>> stuff (demand-mode, BFD auth) which IMO has no business outside of BFD.
>>> 
>>> Agreed. 
>>> 
>>> 
>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers.
>>> 
>>> Perhaps, the addition of multiplier/timers to 
>>> bfd-grouping-base-cfg-parms isn’t pushed to GitHub yet. This version 
>>> https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet
>>> f-bfd
>>> -
>>> t
>>> ypes.yang only has the enabled leaf.
>>> 
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> Reshad.
>>>> 
>>>> 
>>>> 
>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:
>>>> 
>>>>> Hi Reshad,
>>>>> 
>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>
>>>>> 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.
>>>>> 
>>>>> Thanks,
>>>>> Acee
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Reshad.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" <acee@cisco.com> 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 see any reason why 
>>>>>>> client shouldn’t use this directly.
>>>>>>> Thanks,
>>>>>>> Acee
>>>>>>> 
>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" 
>>>>>>> <rrahman@cisco.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi Yingzhen,
>>>>>>>> 
>>>>>>>> The grouping is available @
>>>>>>>> https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yan
>>>>>>>> g/iet
>>>>>>>> f
>>>>>>>> -
>>>>>>>> b
>>>>>>>> f
>>>>>>>> d
>>>>>>>> -
>>>>>>>> c
>>>>>>>> lients.yang
>>>>>>>> 
>>>>>>>> If you¹d like changes to the grouping, send me an email.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Reshad.
>>>>>>>> 
>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" <yingzhen.qu@huawei.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi Reshad,
>>>>>>>>> 
>>>>>>>>> Thanks for the summary.
>>>>>>>>> 
>>>>>>>>> Both ospf and isis models will make corresponding changes when 
>>>>>>>>> the new BFD grouping is available.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Yingzhen
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM
>>>>>>>>> To: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org
>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org; 
>>>>>>>>> draft-ietf-ospf-yang@ietf.org
>>>>>>>>> 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 add back the basic BFD config (multiplier + intervals) 
>>>>>>>>> in IGP via a grouping.
>>>>>>>>> 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).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Reshad.
>>>>>>>>> 
>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas"
>>>>>>>>> <rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org> 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 instancing.
>>>>>>>>>> 
>>>>>>>>>> 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 protocols.
>>>>>>>>>> For
>>>>>>>>>> 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, 
>>>>>>>>>> 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 of the IETF.
>>>>>>>>>>> 
>>>>>>>>>>>        Title           : YANG Data Model for Bidirectional
>>>>>>>>>>> Forwarding
>>>>>>>>>>> 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 configure
>>>>>>>>>>>   and manage Bidirectional Forwarding Detection (BFD).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
>>>>>>>>>>> 
>>>>>>>>>>> There are also htmlized versions available at:
>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06
>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06
>>>>>>>>>>> 
>>>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-06
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 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