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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Aug 2017 10:38:40 -0400

Ashesh,

On Mon, Jul 31, 2017 at 09:39:57PM +0000, Ashesh Mishra wrote:
> 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.  

Remember that configuration and operational state may not be the same.  So,
some rampant speculation:

You configure a desired interval of 50ms.  Both sides support echo.
(Remember that support may be asymmetric.)

It's then permissable for the implementation to decide it can only support
100ms in async mode and bid for 100ms async, 50ms echo.  Once Up, the
session may further backoff its async to something slower.

So, the real question is when echo is supported, what do implementations
supporting that put in their async vs. echo intervals?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Aug 2017 10:41:29 -0400

Mahesh,

On Mon, Jul 31, 2017 at 05:17:34PM -0700, Mahesh Jethanandani wrote:
> > 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? 

Minimally, I'm saying the IGP use is not pulling in the echo grouping either
directly or indirectly.

> 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”;

This seems correct.

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

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.

This minimally suggests that there should be a "use echo mode" flag.

The remaining homework is to figure out whether we should expose
configuration state for echo directly in this version of the yang.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 Aug 2017 08:33:38 -0700

> On Aug 1, 2017, at 7:41 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 

Ahh! That is correct. I was not sure if you were pointing out an issue with the BFD model or the client model(s).

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

> This minimally suggests that there should be a "use echo mode" flag.

Will add a boolean to enable/disable echo mode.

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

> -- Jeff

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Aug 2017 12:33:40 -0400

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

> Will add a boolean to enable/disable echo mode.

I think that's a good start.

> 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 Aug 2017 17:52:01 -0700

> On Aug 1, 2017, at 9:33 AM, Jeffrey Haas <[email-masked]> wrote:
> 

Ok. I have removed the separate configuration values for tx/rx min intervals for echo model. Now, there is only one set of tx/rx values.

> I think that's a good start.

This is what we have now in client-cfg-parms

    container echo-mode {
      if-feature echo-mode;
      leaf echo-mode-enabled {
        type boolean;
        default false;
        description
          "Should be set to true if echo-mode is enabled for this
           session. Set to false by default because defining the
           feature should not enable echo-mode by default.";
      }
    }

Yingzhen, there is one other change that you should be aware of. There is no longer a choice between configuring tx/rx values and a single value for both. Even if the values are the same for tx and rx, you need to configure each of them explicitly. 

I will be uploading the changes shortly.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Aug 2017 12:47:36 -0400

> I will be uploading the changes shortly.

Are we at the point where we should look at the model contents again?

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 7 Aug 2017 10:25:38 -0700

> On Aug 7, 2017, at 9:47 AM, Jeffrey Haas <[email-masked]> wrote:
> 

The BFD model is uploaded and should be evaluated to make sure it meets the requirements of IGP.

Mahesh Jethanandani
[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 14 Aug 2017 15:24:06 +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" <[email-masked]> wrote:

>> 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.
>
>> Per NMDA guidelines, unless the configuration state values are
>>different from config, we do not need to model them as separate
>>attributes.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Aug 2017 13:10:43 -0400

> On Aug 14, 2017, at 11:24 AM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 

Right.  The point was what the echo configuration should look like.  Based on glancing at a couple of vendor configs that use echo, it's mostly "use echo" as a boolean behavior.  This is in contrast with permitting the user to specify distinct echo vs. async timer values.

I'm totally fine leaving the "on demand" case out of scope.

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 14 Aug 2017 17:28:02 +0000

Jeff, I agree. 

Regards,
Reshad.

On 2017-08-14, 1:10 PM, "Jeffrey Haas" <[email-masked]> wrote:

>Right.  The point was what the echo configuration should look like.
>Based on glancing at a couple of vendor configs that use echo, it's
>mostly "use echo" as a boolean behavior.  This is in contrast with
>permitting the user to specify distinct echo vs. async timer values.
>