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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jul 2017 12:21:03 -0400

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, [email-masked] 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/

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 20 Jul 2017 14:18:36 +0000

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.

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 21 Jul 2017 16:22:04 +0000

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:[email-masked]] 
Sent: Thursday, July 20, 2017 7:19 AM
To: Jeffrey Haas <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

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"
<[email-masked] on behalf of [email-masked]> wrote:

>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
>
>> 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.
>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 25 Jul 2017 18:33:07 +0000

Hi Yingzhen,

The grouping is available @
https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd-c
lients.yang

If you¹d like changes to the grouping, send me an email.

Regards,
Reshad.

---

From: Yingzhen Qu <[email-masked]>
Date: Tue, 25 Jul 2017 20:17:04 +0000

Hi Reshad,

Thanks for letting me know. I'll work on the ospf part and keep you posted.

Thanks,
Yingzhen

-----Original Message-----
From: Reshad Rahman (rrahman) [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2017 11:33 AM
To: Yingzhen Qu <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

Hi Yingzhen,

Regards,
Reshad.

On 2017-07-21, 12:22 PM, "Yingzhen Qu" <[email-masked]> wrote:

>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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:07:39 +0000

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:19:27 +0000

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).

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.

Regards,
Reshad.

On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd
>>-
>>c
>>lients.yang
>>
>>>add
>>>>>         Title           : YANG Data Model for Bidirectional
>>>>>Forwarding
>>>>>Detection (BFD)
>>>>>         Authors         : Reshad Rahman
>>>>>                           Lianshu Zheng
>>>>>                           Mahesh Jethanandani
>>>>>                           Santosh Pallagatti
>>>>>                           Greg Mirsky

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:30:00 +0000

Hi Reshad, 

>clients module. I am fine with having everything in the types module (no

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.

>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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:35:30 +0000

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.
bfd-grouping-base-cfg-parms has only the multiplier/timers.

Regards,
Reshad.

On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-b
>>>>f
>>>>d
>>>>-
>>>>c
>>>>lients.yang
>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:40:14 +0000

Hi Reshad, 

>(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/ietf-bfd-t
ypes.yang only has the enabled leaf.

Thanks,
Acee 

>>>>>>Both ospf and isis models will make corresponding changes when the
>>>>>>new
>>>>>>BFD grouping is available.
>>>>>>
>>>>>>Thanks,
>>>>>>Yingzhen
>>>>>>
>>>>>>>> This draft is a work item of the Bidirectional Forwarding
>>>>>>>>Detection
>>>>>>>>of the IETF.
>>>>>>>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 28 Jul 2017 01:03:00 +0000

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)" <[email-masked]> wrote:

>>>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf
>>>>>>-
>>>>>>b
>>>>>>f
>>>>>>d
>>>>>>-
>>>>>>c
>>>>>>lients.yang
>>>>>>
>>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>>>Internet-Drafts
>>>>>>>>>directories.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Jul 2017 02:34:52 +0000

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)" <[email-masked]> wrote:

>>t
>>>>>>bfd-grouping-common-cfg-parms in the other new model. However, I
>>>>>>don’t
>>>>>>see

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:08:48 +0000

Hi Acee,

Got rid of ietf-bfd-clients. I have added example-bfd-client module to
provide an example.

Regards,
Reshad.

On 2017-07-27, 10:34 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>>>>>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ie
>>>>>>>>t
>>>>>>>>f
>>>>>>>>-
>>>>>>>>b
>>>>>>>>f
>>>>>>>>d
>>>>>>>>-
>>>>>>>>c
>>>>>>>>lients.yang
>>>>>>>>
>>>>>>>>>>Thanks authors for the edits on the BFD yang module.  This gets
>>>>>>>>>>us
>>>>>>>>>>a
>>>>>>>>>>On Fri, Jun 30, 2017 at 12:55:59PM -0700,
>>>>>>>>>>[email-masked]
>>>>>>>>>>wrote:
>>>>>>>>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:55:37 +0000

Thanks much Reshad - Yingzhen will be adding but the ietf-ospf-bfd module
to the OSPF model and draft.

Acee 

On 7/28/17, 11:08 AM, "Reshad Rahman (rrahman)" <[email-masked]> wrote:

>>>>>>>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
>>>>>>>>>>The agreement is that since IGP peers are auto-discovered, we
>>>>>>>>>>want
>>>>>>>>>>to
>>>>>>>>>>add
>>>>>>>>>>>with accommodating interaction of the BFD yang module with
>>>>>>>>>>>client
>>>>>>>>>>>protocols.
>>>>>>>>>>>For

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 28 Jul 2017 16:25:54 +0000

Hi Reshad,

Thanks for the update and example. I'll get ospf part done this weekend.

Thanks,
Yingzhen 

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, July 28, 2017 8:56 AM
To: Reshad Rahman (rrahman) <[email-masked]>; Yingzhen Qu <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

Thanks much Reshad - Yingzhen will be adding but the ietf-ospf-bfd module to the OSPF model and draft.

Acee 

On 7/28/17, 11:08 AM, "Reshad Rahman (rrahman)" <[email-masked]> wrote:

>>>-bf
>>>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
>>>>>1) I’ll see if others chime in on this but I am fine with having 
>>>>>the client grouping in ietf-bfd-types.yang.
>>>>>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. 
>>>>
>>>>
>>>>Perhaps, the addition of multiplier/timers to 
>>>>bfd-grouping-base-cfg-parms isn’t pushed to GitHub yet. This version 
>>>>>>>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.
>>>>>>
>>>>>>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 28 Jul 2017 16:28:46 +0000

Thanks Yingzhen. FYI I will be on holiday for the next 2 weeks.

Acee, can you please get in touch with ISIS YANG authors?

Regards,

Reshad.

On 2017-07-28, 12:25 PM, "Yingzhen Qu" <[email-masked]> wrote:

>To: Reshad Rahman (rrahman) <[email-masked]>; Yingzhen Qu
><[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]
>>>>>>>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/
>>>>>>>>>>i
>>>>>>>>>>e
>>>>>>>>>>t
>>>>>>>>>>f
>>>>>>>>>>-
>>>>>>>>>>b
>>>>>>>>>>f
>>>>>>>>>>d
>>>>>>>>>>-
>>>>>>>>>>c
>>>>>>>>>>lients.yang
>>>>>>>>>>
>>>>>>>>>>>BFD will provide that grouping in a specific YANG module. IGP
>>>>>>>>>>>BFD
>>>>>>>>>>>YANG
>>>>>>>>>>>>>    This document defines a YANG data model that can be used
>>>>>>>>>>>>>to
>>>>>>>>>>>>>configure
>>>>>>>>>>>>> Please note that it may take a couple of minutes from the
>>>>>>>>>>>>>time
>>>>>>>>>>>>>of

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 28 Jul 2017 16:30:46 +0000

Hi Reshad,

I'll also take care of the ISIS part. 

Enjoy your vocation!

Thanks,
Yingzhen

-----Original Message-----
From: Reshad Rahman (rrahman) [mailto:[email-masked]] 
Sent: Friday, July 28, 2017 9:29 AM
To: Yingzhen Qu <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

Regards,

Reshad.

On 2017-07-28, 12:25 PM, "Yingzhen Qu" <[email-masked]> wrote:

>>>>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
>>>>I am not sure why you're not seeing something different.
>>>>
>>>>Regards,
>>>>Reshad.
>>>>
>>>>
>>>>
>>>>>>1) I'll see if others chime in on this but I am fine with having 
>>>>>bfd-grouping-base-cfg-parms isn't pushed to GitHub yet. This 
>>>>>version 
>>>>>f-b
>>>>>>>On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" 
>>>>>>><[email-masked]>
>>>>>>>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 
>>>>>>>>enable leaf and others may also want the multiplier/timer.
>>>>>>>
>>>>>>>bfd-types:bfd-client-base-cfg-parms - no? This would be more 
>>>>>>>obvious w/o the client module.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Acee
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>Regards,
>>>>>>>>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)" 
>>>>>>>>><[email-masked]>
>>>>>>>>>wrote:
>>>>>>>>>
>>>>>>>>>>Hi Yingzhen,
>>>>>>>>>>
>>>>>>>>>>On 2017-07-21, 12:22 PM, "Yingzhen Qu" 
>>>>>>>>>><[email-masked]>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>>>Hi Reshad,
>>>>>>>>>>>
>>>>>>>>>>>Thanks for the summary.
>>>>>>>>>>>
>>>>>>>>>>>want to add back the basic BFD config (multiplier + 
>>>>>>>>>>>intervals) in IGP via a grouping.
>>>>>>>>>>>BFD YANG will be in a separate module (separate from the main 
>>>>>>>>>>>IGP module).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Regards,
>>>>>>>>>>>Reshad.
>>>>>>>>>>>
>>>>>>>>>>>>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
>>>>>>>>>>>>
>>>>>>>>>>>>>Internet-Drafts directories.
>>>>>>>>>>>>>Detection of the IETF.
>>>>>>>>>>>>>time of submission  until the htmlized version and diff are 
>>>>>>>>>>>>>available at tools.ietf.org.
>>>>>>>>>>>>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 14:25:27 -0700

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) <[email-masked]> wrote:
> 
> Hi Reshad, 
> 
>>>>>>>>>> properties

Mahesh Jethanandani
[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 28 Jul 2017 21:42:22 +0000

I am fine with this proposal. It will impact other groupings also.

On 2017-07-28, 5:25 PM, "Mahesh Jethanandani" <[email-masked]>
wrote:

>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?
>
>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bf
>>>d-
>>> t
>>> ypes.yang:
>>>is
>>>>fd
>>>>>>> clients module. I am fine with having everything in the types
>>>>>>>module
>>>>>>> (no
>>>>>>> client module).
>>>>>> 
>>>>>>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/i
>>>>>>>>>et
>>>>>>>>> f
>>>>>>>>> -
>>>>>>>>> b
>>>>>>>>> f
>>>>>>>>> d
>>>>>>>>> -
>>>>>>>>> c
>>>>>>>>> lients.yang
>>>>>>>>> 
>>>>>>>>>>>gets us

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 14:44:02 -0700

But do those groupings impact IGP models?

I can take a stab at making the changes before the weekend.

> On Jul 28, 2017, at 2:42 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 15:58:06 -0700

The changes are done and pushed to GitHub. Use the grouping client-cfg-parms.

> On Jul 28, 2017, at 2:44 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Yingzhen Qu <[email-masked]>
Date: Sun, 30 Jul 2017 17:14:28 +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:[email-masked]] 
Sent: Friday, July 28, 2017 2:25 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: Reshad Rahman <[email-masked]>; Yingzhen Qu <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

>> -bfd-
>>>>>>> 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 
>>>>>>> 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
>>>>>>> 
>>>>>>>> https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yan
>>>>>>>> g/iet
>>>>>>>> f
>>>>>>>> -
>>>>>>>> b
>>>>>>>> f
>>>>>>>> d
>>>>>>>> -
>>>>>>>> c
>>>>>>>> lients.yang
>>>>>>>> 
>>>>>>>>> want to add back the basic BFD config (multiplier + intervals) 
>>>>>>>>> in IGP via a grouping.
>>>>>>>>>> to deal with accommodating interaction of the BFD yang module 
>>>>>>>>>> with client protocols.
>>>>>>>>>> For
>>>>>>>>>>> to configure

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 30 Jul 2017 21:42:41 -0700

Yingzhen,

Overall the model looks good to me.

I notice that you decided to (re)define the enable flag in the model. Is that intentional?

You are aware that there is another grouping called client-base-cfg-parms that defines the enabled flag. I am not a particular fan of this split, but I am told that some client protocols just need the enable flag without the rest of the parameters of client-cfg-parms. If the split is confusing, we can collapse the enabled flag into client-cfg-parms.

Thanks.

> On Jul 30, 2017, at 10:14 AM, Yingzhen Qu <[email-masked]> wrote:
> 
> Hi all,
> 
> <ietf-ospf-bfd.tree><ietf-ospf-bfd.yang>

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 13:05:50 -0400

> 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?

-- jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 13:06:54 -0400

> Please let me know your commetns.

This looks fine to me.  I'm even fine with an enable leaf, although disable
is semantically equivalent to removing the configuration.

-- Jeff

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 31 Jul 2017 17:26:43 +0000

Hi Mahesh,

For the enable flag, I'd prefer to have it defined directly in ospf instead of using a grouping from BFD. I'm not sure how useful this grouping is, am I missing something?

Thanks,
Yingzhen

-----Original Message-----
From: Mahesh Jethanandani [mailto:[email-masked]] 
Sent: Sunday, July 30, 2017 9:43 PM
To: Yingzhen Qu <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Reshad Rahman <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt

Yingzhen,

Thanks.

> Cc: Reshad Rahman <[email-masked]>; Yingzhen Qu 
> <[email-masked]>; Jeffrey Haas <[email-masked]>; 
> [email-masked]; [email-masked]; 
> [email-masked]
>>>> f-bfd
>>>>>>>> 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 
>>>>>>>>>>>> to configure  and manage Bidirectional Forwarding Detection 
>>>>>>>>>>>> (BFD).
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 31 Jul 2017 18:56:51 +0000

Hi Mahesh, 

On 7/31/17, 12:42 AM, "Mahesh Jethanandani" <[email-masked]>
wrote:

>You are aware that there is another grouping called client-base-cfg-parms
>that defines the enabled flag. I am not a particular fan of this split,
>but I am told that some client protocols just need the enable flag
>without the rest of the parameters of client-cfg-parms. If the split is
>confusing, we can collapse the enabled flag into client-cfg-parms.

I don’t add ‘enabled’ to the client-cfg-parms? Then a client would only
need a single grouping.

Thanks,
Acee 

>> 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.
>> 
>> 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?
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 31 Jul 2017 19:05:36 +0000

Sigh, I mean “why don’t you add ‘enabled’…"

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 31 Jul 2017 13:06:32 -0700

Yingzhen,

How do you plan to indicate to the BFD engine that the session is enabled?

> On Jul 31, 2017, at 10:26 AM, Yingzhen Qu <[email-masked]> wrote:
> 
> Hi Mahesh,
> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 31 Jul 2017 13:06:49 -0700

Ok. Will do.

> On Jul 31, 2017, at 12:05 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 31 Jul 2017 13:26:48 -0700

Jeff,

> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas <[email-masked]> wrote:
> 

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.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 16:55:46 -0400

Mahesh,

> On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Jeff,
> 

The protocol permits those values to be distinct from the async ones.  They should be in a separate set of params.

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.

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

-- Jeff

---

From: Ashesh Mishra <[email-masked]>
Date: Mon, 31 Jul 2017 21:39:57 +0000

>From what I understand, the echo intervals have an inverse relationship with their control interval counterparts. Faster echo allows for slower control frame rate. So they are necessarily different values. That said, having never implemented echo mode, I can't comment how they should get grouped in the model.  

Ashesh

On Jul 31, 2017, at 4:56 PM, Jeffrey Haas <[email-masked]> wrote:

Mahesh,

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 31 Jul 2017 17:17:34 -0700

> On Jul 31, 2017, at 1:55 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 

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
>> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]